[bind10-dev] Data source development

[Michael Graff]

Jelte Jansen wrote:
> On 12/30/2009 08:13 PM, Michael Graff wrote:
>> Shane has asked if we could have this done by the end of the next
>> bind-10 meeting summit in January.
>>
>> I believe the only hard part right now that I need to solve is simple:
>> Do we use a "compiled" format (where something, either the system or the
>>  admin, compiles a zone into an sqlite3 or bdb format) or do we accept
>> text directly and have an in memory system?
>>
> 
> imo, either is fine right now (the other one should be the first next
> thing anyway)

Agreed.

> i think there's a more important decision; where exactly does the
> 'smartness' live, above or below the data source API? (this choice is
> already implied in your list, separated by the 'if we can't do sigs+' line)

I believe the basic smartness should be "below" the API.  We might 
actually eventually split it into three separate areas:  the server 
proper (which knows only how to ask for records it needs), a 
middle-layer which acts as a smart layer when needed, and a low-level 
layer which acts very close to the data itself.

This was the original discussion from a year ago: the smarts can live as 
close to the database layer itself, or one layer above, if needed.  This 
is done so a simple database can be written fast and easily, and then 
later made faster by migrating the smarts bit-by-bit lower.

The simplest way I can think of doing this is a superclass that has all 
the smarts in it, but doesn't talk to a database directly.  The lower 
layer MUST implement "find this RRSet" and may return signatures.  If 
the zone is marked as signed (probably need zone meta-data in the 
database or at least provided) then this superclass will query for the 
signature RRSET.

Caching may also want to live in this layer as well, perhaps a simple 
"remember for 5 minutes, 50 MB, or unless told to forget my cache" method.

--Michael