BIND 10 #1697: extend MessageRenderer so we can replace the output buffer

[BIND 10 Development]

#1697: extend MessageRenderer so we can replace the output buffer
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120306
                  Component:         |            Resolution:
  libdns++                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  9
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 vorner]:

 > One question first. Maybe I'm missing something, but this way we are
 creating two buffers instead of one each time, right? One private of the
 renderer and one it is set to later. What is the plan about this? How
 should this help to speed things up?

 I'm not sure what exactly you mean by "each time", but it does create
 two buffers if the application explicitly sets a dedicated buffer to
 a renderer by setBuffer().  I wanted to make sure that
 `AbstractMessageRenderer::buffer_` is always non NULL and also allow
 the application not to set a buffer explicitly when it doesn't have to
 replace the buffer every time (or, as a special case of it, when it
 just needs to use the renderer one time).

 For an application that wants to keep reusing the renderer while
 switching the output buffer, the initially created private buffer is a
 waste.  But I thought it's acceptable because an empty buffer is
 pretty lightweight, and the one time creation overhead should be
 marginale when the render is reused.

 > The same message seems to be rendered to two different buffers. What is
 the purpose?

 To be honest, I didn't 100% understand how these buffers are used
 beyond how they are commented:

 {{{#!c++
     OutputBufferPtr msgbuf_;        ///< Buffer corresponding to known
 question
 ...
     OutputBufferPtr expected_buffer_;          ///< Data we expect to
 receive
 }}}

 and from a quick of how they are used in tests.  But in any case, the
 revised code shouldn't change any semantics of the original code: it
 just reuses the same renderer for two different buffers, instead of
 using two different renderers for the two different buffers.  Both
 versions should store the same data to these buffers.

 I've fixed other editorial errors.  Thanks for pointing out them.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1697#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development