[bind10-dev] Data source development

[Michael Graff]

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?

I'd be tempted to do this, as I think it could be pounded out fast by
anyone who knows C++ well (which is not yet me...)

     A tool that takes a flat text file and compiles into SQLite3

     A tool that does the reverse.

     DDNS updates go into the sqlite3 database.

     The database stores a simple wire format (or other fast-to-re-render
     format) of an RRSET.  It has signatures on those records and returns
     them both at once.

     If we can't do sigs + data trick as above, then rrsigs are just
     records and we'll seek and filter when we render.

     A simple cache that sits between data sources and the server
     logic.  Perhaps this cache may be per-data source (with a shared
     maximum size) or perhaps it will be BEFORE any data sources.  I
     sort of prefer the former, as I think it's a cleaner approach.

     When we do REAL caching for a resolver, that is not the same as
     the hot-spot cache described above.

Remember that whatever we do here is not going to be set in stone; we 
can always add to the API, remove from it, etc. as we wish.  We can 
either version the API and eventually remove older ones, or do something 
better like providing default, working-but-not-extremely-efficient 
versions for missing functionality.

--Michael