[bind10-dev] Datasource discussion

[Jelte Jansen]

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

Yesterday, Jinmei, Michael and I had a brainstorm call about the
Datasource API.

I made some notes, but obviously was also active in the discussion,
which is, as notes go, not a perfect situation, so Jinmei and Michael,
please correct me were I my notes fail.

We started out talking a bit about updates, and transactions for that.
Michael suggested earlier that we could look into using diffs; this
could take the form of dynamic dns updates, i.e. a set of prerequisites,
and a set of changes. Then we wouldn't need a full transaction
interface, as the update methods can take care of that.

We agreed on getting the really low-level primitives in place first.
Whether we choose a full transaction-based or DDNS-based solution, we
can then build that upon those primitives.

We then moved on to the find() method. The return value of this should
be more than 'just an integer', as there might be different sets of data
and 'i did this and that, and this is the result' results. We could
define a specific container to return; this would include at least a
direct feedback part (like simply success) and an iterable set of data.
Of course the calling function will need to be able to know the form of
it, so this needs to be defined outside of a specific datasource
implementation.

We discussed efficiency of such a model for a bit, and talked about
smart pointers, allocations and memory copies. For some datasource
types, you wouldn't get around those, while we certainly want to
minimize them for others. Real efficiency will probably have to come
from specialization of the higher-level functions, that actually do know
what the backend model looks like.

Another part of find() is what to pass into it. The minimum of course is
(name,class,type), but for some searches we might need either some form
of 'extended-type', or perhaps even 'this rdata field must match X'.
We'll first do only the first, and look at the second when we need it.

We agreed that including signatures in any result would be a relatively
simple optimization that all datasources would probably want to make
anyway. For this, we want the RRset class to have an attribute to store
signatures. There should be a way to tell find() not to add them, and
perhaps some datasources might simply not do it. For NSEC(3)s, we are
(or at least I am) not sure on whether it is possible to also add those
in one call, should the name not be found. If there are multiple, we may
have a bit of a problem if the zone changes while we are building the
result. This is a specific case of a more general problem though, which
needs to be resolved anyway.

During the implementation of the prototype for the first datasource
proposal, I found that is really annoying that RRset name, type, class
and TTL must be set on creation time. We might need to add functions to
do this later or change them to the API, but then again, with a more
advanced datasource API, this will probably not be necessary.

The last topic of discussion was how the concept of zones fits into all
of this. Michael already sent out a separate message for this.

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

iEYEARECAAYFAktNoPsACgkQ4nZCKsdOncXdnQCfRrL7MDERmohS/vTj7E0/QWYV
yfkAoLPvCY6QrLrpxOhBPfa2ZD6FRni8
=fnBx
-----END PGP SIGNATURE-----