BIND 10 #2095: Define and implement `RdataEncoder` class

[BIND 10 Development]

#2095: Define and implement `RdataEncoder` class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> The name and the class spec are derived from my experiments, but it
> doesn't have to be that way.  Think about the best design and
> implement it.  In my experimental version it would look like:
>
> {{{#!cpp
> class RdataEncoder : boost::noncopyable {
> public:
>     RdataEncoder(); // can be default-constructed
>
>     // Internally "add" the given RDATA.
>     void addRdata(const dns::rdata::Rdata& rdata);
>
>     // Internally "add" RRSIG for the RDATA.  It's supposed to be of
> RRSIG.
>     void addSigRdata(const dns::rdata::Rdata& rdata);
>
>     // After a sequence of calls to addRdata()/addSigRdata(), prepare
>     // internally state for actual encoding.  call to addXXX after
>     // this point will be invalid.
>     void construct(dns::RRType type);
>
>     // Return the size of storage for the entire data in the encoder.
>     // only valid after construct().  The caller will allocate necessary
>     // storage using it.
>     size_t getStorageLength() const;
>
>     // encode the internal data  starting from the given pointer.
>     // the caller should have allocated sufficient space.
>     size_t encode(void* data, size_t data_len) const;
>
>     // Reset internal state for reuse.  After this call, the caller can
>     // restart encoding from addXXX.
>     void clear();
> }}}
>
> This class will internally use something similar to things internally
> used in libdns++'s RdataFields (specialized renderer).
>
> Depend on #2094

New description:

 The name and the class spec are derived from my experiments, but it
 doesn't have to be that way.  Think about the best design and
 implement it.  In my experimental version it would look like:

 {{{#!cpp
 class RdataEncoder : boost::noncopyable {
 public:
     RdataEncoder(); // can be default-constructed

     // Internally "add" the given RDATA.
     void addRdata(const dns::rdata::Rdata& rdata);

     // Internally "add" RRSIG for the RDATA.  It's supposed to be of
 RRSIG.
     void addSigRdata(const dns::rdata::Rdata& rdata);

     // After a sequence of calls to addRdata()/addSigRdata(), prepare
     // internally state for actual encoding.  call to addXXX after
     // this point will be invalid.
     void construct(dns::RRType type);

     // Return the size of storage for the entire data in the encoder.
     // only valid after construct().  The caller will allocate necessary
     // storage using it.
     size_t getStorageLength() const;

     // encode the internal data  starting from the given pointer.
     // the caller should have allocated sufficient space.
     size_t encode(void* data, size_t data_len) const;

     // Reset internal state for reuse.  After this call, the caller can
     // restart encoding from addXXX.
     void clear();
 };
 }}}

 This class will internally use something similar to things internally
 used in libdns++'s RdataFields (specialized renderer).

 Note: For now, we'll encode names in the form of serialized
 `LabelSequence` (namelen, offsetlen, namedata, offset data) instead of
 pointers.  This is different from the ultimate proposed version in the
 wiki.

 Depend on #2094

--

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