[bind10-dev] writable datasources 1/3; data_source.h

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Writable datasources

Hi,

I've been thinking a bit about writable data sources, and have half a
proposal for the API. There are quite a few open issues, and I think
we'll find many more once we actually start building this. But I figured
let's start the discussion anyway (the assignment was strawman proposal,
right? :) ).

I'm splitting this up in 3 messages, Hopefully that keeps the different
discussions nicely threaded in the archives.

First of all, I have a few comments on and questions about data_source.h
as it is (i.e. also for the current read-only data source API).

It seems to be quite lacking in the form of doxygen comments. The
methods are generally self-describing, but since we are expecting people
to be able to write their own, we should be really specific about
exactly what every function is supposed to do, especially the low-level
ones, that have to be overridden. Even more so than for 'normal' API's
IMO. Currently, the comments that are in there mainly specify which
function you could or should not override, which is mostly deferrable by
their type. But what a data-source writer needs to know is exactly how
every low-level function is supposed to act when called from the default
high-level ones.

Speaking of should and should not override, there is a comment in there:

    // 'High-level' methods.  These will be implemented by the
    // general DataSrc class, and SHOULD NOT be overwritten by subclasses.

I thought the idea was that these functions don't *need* to be
overwritten, but *could be* if the implementor wants to (for instance to
make use of specific backend features). That SHOULD NOT there doesn't
really seem to imply that :)

I'm also wondering whether we should make the low-level functions
private. Do we expect these to be used directly? (in which case, I'm
wondering whether we even need some of the high-level ones that I
currently have for the writable part, as I suspect tools like loadzone
might want to use the low-level ones so they can read/store one rr at a
time instead of loading an entire zone into memory, just to name something).

To be continued.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvnxsIACgkQ4nZCKsdOncUyIgCgvf1e9woDFVukZ7JuiIYbV1Hm
JJ0An3CaQdq5aOzhHy3qx1ZrFZt7YdLi
=Ue2W
-----END PGP SIGNATURE-----