[bind10-dev] Datasource API

[Jelte Jansen]

On 01/05/2010 09:43 PM, JINMEI Tatuya / 神明達哉 wrote:
>> 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)
> 

thanks, let me also quickly answer before i go to bed then :)

> - 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.

as opposed to providing an implementation in the base class for those
functions that don't necessarily need to be changed for different data
sources?

> 
> - 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?
> 

that's a big part of my question on where the intelligence should be :)

> - 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"
> 

actually, in this example, noerror/nodata would just end up with an
empty target rrset, but a success return code

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

no problems with that,

> 
> - 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.
> 

yep, and probably everything efficient should, but that's the reason i
was thinking of lowlevel and highlevel functions, where if they are
encapsulated in one class, the efficient end-result would have those
high-level ones take quite a lot of shortcuts. Though i'm open to
suggestions or loud no-shouting :)

> - 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.

good point, for single rr add(), i'd say always add, and use
remove/readd to change. For rrsets this might be a bit more complicated
(although simply replacing them would certainly be an option, you could
always get them before)

> 
> - 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?
> 

yeah, at first i thought of trying to find the corresponding zone first,
then use that as a handle for the actual data search, but perhaps we
could also provide it all in passed arguments

> - 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.
> 

well see my second and fifth answer (on intelligence and efficiency),
i'm certainly not set in stone on the current approach (nor for other
choices made so far)

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

oh yeah, of course :)

Jelte