BIND 10 #415: new query logic for in memory data source (1)

BIND 10 Development do-not-reply at isc.org
Mon Dec 6 06:11:44 UTC 2010


#415: new query logic for in memory data source (1)
---------------------------+------------------------------------------------
      Reporter:  jinmei    |        Owner:  jinmei               
          Type:  task      |       Status:  reviewing            
      Priority:  major     |    Milestone:  y2 12 month milestone
     Component:  b10-auth  |   Resolution:                       
      Keywords:            |    Sensitive:  0                    
Estimatedhours:  0.0       |        Hours:  0                    
      Billable:  1         |   Totalhours:  0                    
      Internal:  0         |  
---------------------------+------------------------------------------------

Comment(by jinmei):

 Replying to [comment:3 jelte]:
 > I don't have an overview of the entire design and where it fits in (and
 comment on that would be out of scope for this ticket anyway), so i'll
 keep it localized;
 >
 A higher level idea is documented here:
 http://bind10.isc.org/wiki/AuthQueryLogic
 (although I'm not sure if this give you an overview you mean here)

 > I only have a few questions/comments, nothing really source code-related
 (that looks ok)
 >
 > - This introduces a second Query class, under a different namespace. Is
 it supposed to replace the one under datasrc::? I know that that is what
 namespaces are for, but we tend to use 'using namespace' (which itself i
 don't really like anyway, btw), and the potential confusion does worry me
 a bit.
 >
 Not necessarily "replace", but we should eventually merge the two modules,
 at which point there will be only one "Query" class.  I was actually aware
 of the duplicate name and possible confusion, and considered a different
 name "AuthQuery" just to avoid the ambiguity.  But I chose not to do so
 because the name sounds redundant in some sense and the ambiguity will be
 temporary anyway.

 > - note: If I read this correctly, the Rcode that would in the end be set
 by this code for data that is not found changes from current behaviour
 (right now it returns REFUSED, not SERVFAIL). I prefer this new one (and
 do REFUSED because of ACL, not data presence) :)
 >
 Your understanding is correct.  I know it's different from the typical
 response of BIND 9 in this configuration and BIND 10's libdatasrc.  If
 compatibility with BIND 9 in this case is important, I don't mind changing
 the behavior, but I guess this will be a broader question and we should
 discuss it at the bind10-dev list.

 > - One of the example for future changes in the comments say that we may
 consider returning the Rcode instead of setting it in the provided
 response message. If the process() function is going to modify the
 response by adding results anyway, i think we should also set the Rcode in
 it. We can then still decide to also return it (or a different simple
 value that represents success/error)
 >
 Okay, I've updated the doxygen comment accordingly.

 I've also updated the comments for the other two points, and I'm going to
 merge this version to trunk.  If some of the questions require a further
 change, we'll handle it as a separate task.

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


More information about the bind10-tickets mailing list