[bind10-dev] BIND 10 trac503, updated. implement ANY query logic

[JINMEI Tatuya / 神明達哉]

At Wed, 26 Jan 2011 21:26:01 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > RRsetList is not actually a "list".  It's actually a "set of RRsets",
> > and its "add" method internally performs "insert it if it's not
> > already in the set", which is expensive.
> 
> Then may I point out the name is probably misleading? I didn't look
> the class up in the documentation, but I expected by the name that
> it is just a vector wrapped in something.

Yes, that's a valid argument.  We were aware that it was named badly,
but we couldn't come up with a better name for the concept of "a set
of RRsets": RRsetset would look awkward; RRsets would be confusing
(with RRset).  So we left the name unchanged.  Such a background story
should have been documented, but at that time we didn't have time for
that either...

> > I also have a concern with the new find() interface.  It looks awkward
> > that it (can) return a requested type of RRset as a return value while
> > also providing all types of RRsets via the "target".
> 
> Not really. Currently it returns only when there's no exact match on
> rtype (eg.  if it would lead to NXRRSET). But if it would be used
> for anything else, that might still change.

I know that.  My concern is more about the interface itself

> So, while not completely disagreeing with you, may I propose
> something? Leave it as it is right now, because the thing
> works. Later we will be merging interfaces of in-memory datasource
> and the SQLite datasource and will need to come up with something
> common. It will cause earthquake in the interfaces, so why don't we
> solve it after then?

Works for me.  I'll update the documentation for Zone::find() with
noting this point (btw the current documentation seems insufficient.
It only briefly mentions the new "target" parameter in the parameter
list).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.