BIND 10 #2094: Define and implement RDATA field specs

[BIND 10 Development]

#2094: Define and implement RDATA field specs
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  accepted
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120731
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 trac2094 is ready for review.

 First, I introduced a proposed organizational change: create a
 "memory" subdirectory under lib/datasrc and define necessary stuff
 there.  It will be handled as automake convenience library, so from
 the library-organization point of view, it's still part of libdatasrc
 (or if we want to make it a loadable module again, we can do so
 easily).  The in-memory related stuff will be pretty big, so I thought
 it makes sense to have a clearly separated workspace.  If this
 approach makes sense, we'll copy/move revised version of
 rbtree/memory_datasrc, etc, under this subdirectory as we implement
 them.

 Second, I did some not-directly-related changes.  They are noted so
 in the commit log, plus 69d4850 (as for 69d.. I could use the libdns++
 version, but I believe we should move it to some DNS-independent place
 eventually.  I thought it's the time for it).  Some of the changes are
 bug fixes as commented in the commit log, and may not necessarily have
 to be addressed in this ticket, but fixing them will make tests
 easier, and the fixes should be small and trivial.

 The main changes are actually small, but reviewing it may be boring
 because it's essentially a list of definitions.  All non trivial cases
 have been explicitly tested so I'm quite confident they are accurate.
 I guess it's sufficient to do overall sanity check, instead of making
 sure each and every definition is correct (if the reviewer is willing
 to do it, that's highly appreciated though).

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