BIND 10 #1607: define ZoneFinder::findAdditional() and implement its default version

[BIND 10 Development]

#1607: define ZoneFinder::findAdditional() and implement its default version
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120306
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4
Feature Depending on Ticket:  auth   |           Total Hours:  0
  performance                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:11 jinmei]:
 > Hmm, good point.  I didn't think about it but that seems to make some
 > sense.  I personally still think it makes sense to define findAll()
 > separately from find() rather than relying on the implicit meaning of
 > qtype=ANY, but at least we can unify the interface.

 Agreed.

 > Would you like to introduce the change now, or should it go to a
 > separate ticket?

 Hmm, I don't really want to slow the ticket down too much, but it would be
 nice to have all the interface changes at once, if at all possible. So, if
 it isn't too much work, I'd prefer it now.

 > > Another thing, maybe we want to have a abstract base class that
 contains no data members like the vector for the all thing. I could
 imagine the in-memory remembering the node only and iterating that one
 when needed, instead of copying it out to a vector to iterate later.
 >
 > Right.  I was aware of that, and in fact I liked the clearer
 > separation of abstract interface from stuff that may not be used by
 > all derived classes.  I still pushed vector, etc, to the base class
 > because if a derived class wants partial customization (e.g., use
 > customized version for getNegativeProof() if it's ever introduced but
 > still use the default version of getAdditional()), it'll still needs
 > to get access to things for the default version.  I also expect if we
 > extend the context it may need to remember other information such as
 > the original qname (in case wildcard expansion happens), and so the
 > base class would retain a pointer blob, such as:
 > and allow a fully-customized implementation to keep it NULL.
 >
 > Alternatively, we could define a protected method such as
 > getAllRRsets(), getFindOptions(), etc, and the default implementation
 > of getAdditional() would use getAllRRsets() to get access to the
 > RRsets that were possibly found by findAll().  Then we can move the
 > member variables to a separate derived class:

 Well, my original idea was to have the abstract base class without any
 guts. Then there'd be a default base class (something like the current
 version), that would be used if someone wanted no customization or just a
 partial customization. And if some datasource felt really brave, it could
 go and do full customization on top of the very abstract one.

 I don't think it makes sense to do anything too complicated because of the
 vector, if they'll be reused, an empty vector that is just sitting there
 is not a big problem.

 > Regarding this, my suggestion is to keep it for now, and see how
 > easy/difficult to implement the customized in-memory version, and then
 > think about better reorganization based on the experience.

 OK, no problem.

 > > The python interface is not changed. Is it planned to any other
 ticket? Because it would not be possible to call the getAdditional, etc,
 from python right now.
 >
 > [...]
 >
 > Maybe we should just create a ticket mentioning the possibility so we
 > can revisit the point later.   If we see as stronger need at that
 > point, we can add it; if not, maybe that indicates it's unlikely that
 > python apps need it and we can forget it for a relatively longer term.

 OK, that sounds reasonable. If someone wants decent speed with python…
 Hmm, right, makes no sense anyway. A ticket seems enough (maybe with the
 ticket number mentioned in the wrappers code somewhere).

 Thanks

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