BIND 10 #2377: define dns::MasterLoad class

[BIND 10 Development]

#2377: define dns::MasterLoad class
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  libdns++      |  accepted
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20121204
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  7             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I just saw this jabber message:
 {{{
 I'm writing the master loader now. And it seems the tickets suggest it
 should not only load, but also collate RRsets together, if they are
 consecutive. But I think that is the wrong approach.  For one, the
 recipient needs to be able to collate them anyway (because it might
 not be consecutive), so it would be duplicate effort and it would also
 mean the loader does more than one thing, making it impossible for the
 recipient to get separate RRs.
 }}}

 On thinking about it for a while, I think I tend to agree - it's
 probably better to let `MasterLoader` focus on converting a sequence
 of textual RRs to a sequence of (some native form of) RR objects.

 But at the same time, I suspect it's more convenient if each
 application of the `MasterLoader` doesn't have to write its own
 collating code.  Often a zone file is well grouped (especially so in
 the era of DNSSEC when a zone file to be loaded is usually
 preprocessed), so a naive collate algorithm (like the current
 masterLoad()) usually produces a complete set of RRsets and should
 suffice.

 Another thing: if we let `MasterLoader` only generate individual RRs,
 I'd like to avoid using (a derived class of) `RRset`; the code given
 an RRset needs to care about various unrelated things: the number of
 Rdata (which can even be 0), whether it's "signed" or not, etc.  So
 I'd introduce another data structure to exploit the fact that it's
 just one single RR.

 Considering these, if we adopt the separate-RR approach, what I'd
 envision is something like this:

 {{{#!cpp
 // This is type of functor to be called from MasterLoader for each
 // recognized RR
 typedef boost::function<void(const Name& name,
                              const RRClass& rrclass,
                              const RRType& rrtype,
                              const RRTTL& rrttl,
                              RdataPtr rdata)> AddRRCallback;

 class MasterLoader {
 public:
     MasterLoader(AddRRCallback add_callback, ...);
 };

 typedef boost::function<void(const RRsetPtr& rrset)> AddRRsetCallback;
 class RRConsolidator {
 public:
     RRConsolidator(AddRRsetCallback callback);

     // Internally build RRset from the given RR parameters, and call the
     // RRset callback when it encounters a new name or new type
     void add(const Name& name, const RRClass& rrclass,
              const RRType& rrtype, const RRTTL& rrttl,
              RdataPtr rdata);
 };

 // User application code
 RRConsolidator consolidator(my_callback);
 MasterLoader(boost::bind(&RRConsolidator::add, &consolidator, _1, _2, _3,
 _4, _5));
 }}}

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