BIND 10 #2309: define ZoneFinder::findAtOrigin()

[BIND 10 Development]

#2309: define ZoneFinder::findAtOrigin()
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  6             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Thanks for the review.

 Replying to [comment:14 vorner]:

 > Is the copyright header year OK in the new file (zone_finder.h). I know
 the code is just one taken from elsewhere, but it's new file on the other
 hand. I'm not sure how these copyright matters work.

 I wondered that and chose to keep the original year as that's the
 year when the contents of the (new) file first appeared.  But I
 actually didn't have a specific opinion or preference, and as you
 probably noticed, asked it on jabber.  The suggestion seems to keep
 the original year, so I've not changed it.

 > There might be needed a comma in this commend after RRTTL, this way it
 looks like a minimum from 3 values:
 > {{{
 > // so we specify the use of min(RRTTL SOA MINTTL) as specified Section 3
 > }}}

 Good catch, fixed it.

 > Also, I'm not sure I really like the idea with having a public interface
 just wrapping the `getAtOriginImpl`. Is it really likely the interface
 would change in a way the implementation could stay the same? What is
 special about this case so it is handled exceptionally? I don't know if
 it's worth the added layer of complexity. I'm not worried about the speed
 of produced code, it should be the same, since compiler will just inline
 it and optimise the call out, but the complexity of following the code.

 Okay, it was actually a last minute change (not the original design
 plan), and if you don't like it I'm okay with reverting it.  And I've
 done that.

 Regarding this design policy, I believe it's a well known practice in
 C++ and actually suggested in some literature.  The key of the
 decision point is how likely we'll want to change the interface for
 the actual implementation, and, IMO, we (people in general) tend to
 underestimate that possibility.  So, I'm basically convinced about the
 practice.  But we don't use it in the rest of the code much anyway, so
 in terms of consistency it may look awkward, and since this interface
 is not expected or intended to be used by other general applications
 (although, again, we tend to be too optimistic about such
 expectation), I'm okay with reverting this particular case as it was
 questioned.

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