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