BIND 10 #2107: redefine in-memory zone data

[BIND 10 Development]

#2107: redefine in-memory zone data
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120821
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            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:

> We'll need a memory encoded form of zone data.  My suggestion
> is to revise the current `ZoneData` structure so that it will be
> simpler data-only structure, and allocated/deallocated using
> static method and a memory segment, e.g.:
>
> {{{#!cpp
> template <typename TreeType, typename TreeNodeType>
> struct ZoneData {
>     static ZoneData* allocate(MemorySegment& segment, RRClass
> zone_class,;
>                               const Name& zone_name);
>     static void deallocate(MemorySegment& segment);
>
>     // These will be initialized on allocation and won't change
>     const RRClass zone_class;
>     // some other attributes
>     offset_ptr<TreeType> const tree;
>     offset_ptr<TreeNodeType> const origin_node;
>
>     const RBTree& getNSEC3Tree() const; // for ZoneFinder
>     RBTree& getNSEC3Tree(); // for ZoneUpdater/loader
> private:
>     offset_ptr<TreeType> nsec3_tree_;  // build this on-demand
> };
> }}}
>
> This is essentially a private structure for other implementation
> details of in-memory data source client (finder/updater, etc), which
> will use the member variables directly.

New description:

 We'll need a memory encoded form of zone data.  My suggestion
 is to revise the current `ZoneData` structure so that it will be
 simpler data-only structure, and allocated/deallocated using
 static method and a memory segment, e.g.:

 {{{#!cpp
 template <typename TreeType, typename TreeNodeType>
 struct ZoneData {
     static ZoneData* create(MemorySegment& segment, RRClass zone_class,;
                             const Name& zone_name);
     static void destroy(MemorySegment& segment, ZoneData* zone_data);

     // These will be initialized on allocation and won't change
     const RRClass zone_class;
     // some other attributes
     offset_ptr<TreeType> const tree;
     offset_ptr<TreeNodeType> const origin_node;

     const RBTree& getNSEC3Tree() const; // for ZoneFinder
     RBTree& getNSEC3Tree(); // for ZoneUpdater/loader
 private:
     offset_ptr<TreeType> nsec3_tree_;  // build this on-demand
 };
 }}}

 This is essentially a private structure for other implementation
 details of in-memory data source client (finder/updater, etc), which
 will use the member variables directly.

--

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