BIND 10 #1575: move data_source.cc:Nsec3Param to libdns++

[BIND 10 Development]

#1575: move data_source.cc:Nsec3Param to libdns++
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120207
  critical                           |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:4 jinmei]:
 > I think it's worth a changelog entry.  This is the proposed one:
 >
 >       libdns++: a new class NSEC3Hash was introduced as a utility ofn

 I believe there's a typo (should it be utility *for*…?).

 Does Doxygen generate the „brief“ descriptions from the first paragraph
 automatically? It seems so, but I'd prefer having them there, just for the
 clarity.

 The word „alphabets“ looks wrong, I believe an alphabet is a set of
 characters a language uses to write its words (like Czech alphabet, Greek
 alphabet, …). Would „letters“ be better? (both in C++ and python docs)

 The error message „function must be given NSEC3HASH Rdata“ is possibly
 correct according to English rules, but it took me like 5 seconds to parse
 it, as the nominative is at the end. Maybe something „You must provide a
 NSEC3HASH Rdata to the function“.

 I'm little bit worried about the future extendability of this class. Would
 it be better to have a pointer (shared pointer, or whatever) returned from
 a static function? That way each algorithm could have its own concrete
 implementation of the class, if needed, and the function could decide
 which one should be created. This would also remove the need for having a
 private implementation class (!NSEC3HashImpl), as the concrete class could
 be effectively hidden. I understand this implementation is temporary, as
 good for now and we don't need to support eg. md5. But I'd propose at last
 changing the interface (to have the function be virtual and allocation
 being done by the static function), so we can keep it when we revisit it
 and generalise it.

 Also, every time I see the python wrapper file generated form the
 template, I wonder if we should leave the comments about what should be
 done to fill in the template in, as this looks as something was forgotten
 to be done. But that might be for a wider discussion than just this
 ticket.

 Thank you

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