BIND 10 #1207: Enable the data source factory

[BIND 10 Development]

#1207: Enable the data source factory
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  stephen                            |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120515
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => UnAssigned
 * status:  assigned => reviewing


Comment:

 Okay, so as known, this work couldn't be done completely just yet, but I
 think I got as far as we can given the pending work
 (metadatasource/container, and zone loading v2), and this branch is
 getting quite big already, and I think it will make the next steps much
 easier if we include it.

 The changes are nearly all related to the in-memory data source; the
 sqlite3 one is used as part of ye olde MetaDataSrc, and we can change
 that, but then we'd lose the static data source (or get some really kludgy
 query handling), so I left that specific part alone, pending the
 meta/container work. However, I think that those changes will be less
 severe, as the metadatasource already abstracts away the sqlite3 db pretty
 well.

 It did not do so for the in-memory stuff, so I have mostly been focusing
 on getting the direct references to InMemoryDataSource out of auth_srv. I
 have mostly succeeded, save for one handler in command.cc; the zone reload
 command (ZoneFinder->load() does not exist, and we can't create abstract
 zone finders, so either we need to add (re)load to the base ZoneFinder
 class, and depending on how it would work, a lightweight clone for
 ZoneFinders (that creates one of the same type, class and origin, but not
 contents), or be able to send messages to do things directly to
 instantiated datasources. If this work is not yet part of the new zone
 loading stuff, I can add tickets for the former option. Would at this
 point not know how to approach the latter :)

 The tests also contain a number of InMemoryDataSource-specific calls
 (mainly related to zone loading as well). I did move one of them 'up' to
 the DataSourceClient level; getZoneCount() to return the number of 'known'
 zones (or raise NotImplemented), as this one seemed quite useful for most
 if not all datasources.

 But since nearly all of them are out of auth itself now, it should be much
 easier to convert the entire thing into a general meta/container. There is
 still a separate getter/setter for 'inmemorydatasource' but it returns and
 takes a general DataSource now, and it is there for behavioural reasons
 (As the 'other' datasources are still handled the old way, pending
 etc.etc.etc.)

 There should be no changes to exterior behaviour (or way to set it up), so
 i don't think we need to have a changelog entry (but we probably do want
 to up ABI versions).

 Oh, and if you happen to prefer looking at individual commits, i have been
 trying to put more info in the commit messages. However, to keep my sanity
 while doing this work, I have introduced some temporary calls and members,
 which have later been removed again, so the final full diff is probably
 much less work to inspect.

 So unless we have other tickets that define this work already, we need at
 least two new ones:
 - the metadatasource/container work (as currently discussed on -dev)
 - port static datasource to new API and/or include it directly in query
 handling
 - add zone-loading functionality to either the general DataSource API or
 - set up the above instead of the current MetaDataSrc class (and remove
 the special handling for inmem)

 And then we can *finally* get rid of the old API :)

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