BIND 10 #1574: Add support for loading NSEC3 RRsets to in memory data source

[BIND 10 Development]

#1574: Add support for loading NSEC3 RRsets to in memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120207
  critical                           |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  7
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:  NSEC3  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 vorner]:

 > Reading throuh it, I find just one problem (provided the tmp method will
 be replaced by a real one in a future ticket). Why do you create the
 ToUpper class? It doesn't hold any state or like that. Shouldn't transform
 be able to take toupper directly?

 Unfortunately not, because the signature doesn't fully match.
 transform expects char(*)(char), but toupper's type is int(*)(int).
 But it doesn't necessarily have to be a functor, but an ordinary
 wrapper function

 {{{#!c++
 #ifdef instead_of this
     struct ToUpper {
         char operator()(char ch) { return (toupper(ch)); }
     };
 #endif
     char ToUpper(char ch) { return (toupper(ch)); }
 }}}

 If you prefer it, I'm okay with changing that (hmm, and maybe in an
 unnamed namespace outside the class, because it's independent from
 class internals).

 BTW, for now I've moved the definition of ToUpper a bit, as it seemed
 more reasonable.

 > Also, I know it's not problem of this branch itself, but we require some
 ordering of data in the zone file (or more precisely, the input stream).
 When do we want to change it? Because a database might give it in any
 order, so can (in theory) be in the zone file.

 I think we should solve this either when we want to support loading
 from a different data source or when we support generic (and more
 correct than b10-loadzone) master file parser.  Right now, in-memory
 data source requires preprocessing with BIND 9's named-compilezone in
 practice, and its output meets the requirement, so the assumption is
 safe.

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