BIND 10 #825: Make callbacks for auth and recurse the same (item 56 from f2f)

BIND 10 Development do-not-reply at isc.org
Thu Mar 31 10:44:44 UTC 2011


#825: Make callbacks for auth and recurse the same (item 56 from f2f)
-------------------------------------+-------------------------------------
           Reporter:  jelte          |                      Owner:
               Type:  task           |                     Status:  new
           Priority:  major          |                  Milestone:  Year 3
          Component:  Unclassified   |  Task Backlog
          Sensitive:  0              |                   Keywords:
Add Hours to Ticket:  0              |  Estimated Number of Hours:  0
        Total Hours:  0              |                  Billable?:  1
                                     |                  Internal?:  0
-------------------------------------+-------------------------------------
 Currently, our _servers (tcp_ and udp_) get set up with a
 DNSLookup'Provider' and a DNSAnswer'provider' (and a third callback, but
 that is not relevant right now). These 'providers' are in the form of
 callbacks with the following signature:

 virtual void operator() { io_message, query_message, answer_message,
 buffer, server).

 The query_message contains the query as received from the client, the
 answer message contains the message we shall send back, and the buffer
 contains the rendered message we shall send back.

 Either answer_message or buffer is redundant in this scenario.
 Additionally, they are currently inconsistently used by auth and resolver.

 Originally I thought we should only clean that last part up, but I now
 think we should probably remove buffer completely from the callback, or
 only add it to the last one (DNSAnswer). I think that answer_message is
 more flexible than a completely rendered buffer (we actually use it for
 some final modifications in the second callback in the resolver),

 Removing or updating it would be a bit more work that it might initially
 seem; there are a lot of calls that buffer is propagated to. These are
 afaict not difficult changes, but it would touch a lot of files.

-- 
Ticket URL: <http://bind10.isc.org/ticket/825>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list