BIND 10 #1332: Implement ZoneJournalReader class

BIND 10 Development do-not-reply at isc.org
Fri Nov 18 12:32:55 UTC 2011


#1332: Implement ZoneJournalReader class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:11 jinmei]:
 > This actually used the type conversion operator of the shared pointer
 class,
 > and in that sense it's something not covered by the style guideline.
 >
 > I don't have a strong opinion about how to do this in this case, and
 > I actually don't like relying on implicit type conversions too much,
 > but in this case alternatives don't seem to be attractive either:

 I don't mind it, I actually find it pretty readable. I was corrected
 several times that I shouldn't write stuff like `if (pointer)`, so I
 thought this is the same. I myself find it quite natural to evaluate a
 pointer in boolean context, with implicit question „is there something?“.

 So, as for me, keep it the way it is. I was just wondering if you happened
 to overlook it as it usually happens to me.

 > >  * The database is expected to hold if a given diff is addition or
 removal. Why doesn't the interface provide this information? One comment
 says that an application might want to explicitly check that it is correct
 IXFR sequence, but it can't really do so without this information.
 >
 > Because it's basically part of the interface contracts (i.e., if it
 > doesn't hold it's a bug of the underlying implementation or someone
 > intentionally tweak the data by hand).  An applicatoin can check (if
 > it really wants) the sequence is valid just like when xfrin checks the
 > sequence is valid from an IXFR response (which doesn't contain an
 > explicit flag of add or delete).

 No, I'm OK with the behaviour, considering that the only use we will have
 will probably be in IXFR-out anyway. It just didn't look too much
 consistent with the comment about checking. Maybe the comment could be
 neutralized slightly?

 Anyway, I think it can be merged (with or without a change to the comment,
 as you see fit).

 Thanks

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


More information about the bind10-tickets mailing list