[bind10-dev] Datasource API

[JINMEI Tatuya / 神明達哉]

> Based on this, i think i could get a DataSourceParkingLot done pretty
> quickly, but if anyone thinks this is completely not the way to go,
> please let me know before tomorrow ;)

Some quick and blunt comments before I leave for lunch (and you go to
bed:-).  Comments are random, mixed with minor style issues and
discussions about the API design.  (I'm not intending to prevent you
from starting the prototype though)

- in general, I'd like to separate the abstract base class from a
  concrete implementation class.  in that sense, I'd separate the
  default implementation class from the base DataSource class.

- how would we represent non trivial match?  For example, matching a
  CNAME, partial match at a zone cut?  Wildcard match (may be it's not
  special in this context)?

- What about RFC2181 data ranking?  Should we separate glue and
  authoritative data in matching?  How would that affect the API?

- on a related note with the previous point.  we may have to provide
  more detailed information in the result codes.  on another related
  note: we'll need to represent "name exists but no data"

- minor comment on method naming: s/get/find/?.  getXXX sounds like a
  straightforward accessor, but getRRset() (e.g.) would be much more
  intelligent.


- interface to handle SIGs: should we separate this from getRRset()?
  FYI, BIND9 uses a unified "find" interface to get both the answer
  and its SIG by a single lookup.  If my memory is correct NSD does
  the same thing.

- addRR: why not adding RR? (we have the "RR" class).  Also why not
  RRset?  it's also not clear whether this "add" is "replace" or
  "merge" if there's data of the same name/type exists.

- if this is a compound source of data (i.e., containing multiple
  zones), do we need to provide/add to an interface to indicate which
  zone a find matches?

- in BIND9 (for example), we model the "data source" as consisting of
  + zones
  + zone DBs (1-to-1 mapping between zone and DB)
  + DB nodes (searched by domain names)
  + rdatasets in a DB node (per RR type)

  And we can search for either a "node" (key = name) or an rdataset
  (key = name + type).   If we get a "node", we can then iterate over
  all rdatasets in the node to examine all (RR) types of data.
  should we provide the same level of search granularity?

- about the high level method (getData()): I'm afraid this will make
  the class too monolithic.  maybe we can begin with a non member
  function only using other low-level public methods.

- minor coding style point: I'd generally pass 'const T&' instead
  of 'const T' for the purpose of search key or something like that.

---
JINMEI, Tatuya