[bind10-dev] xfrin (was Re: revised/refactored data source design proposal)

[JINMEI Tatuya / 神明達哉]

At Tue, 07 Jun 2011 11:16:39 +0200,
Jelte Jansen <jelte at isc.org> wrote:

> I think the way to handle transfers-in are backend-specific, and
> that xfrin should not be aware of the way any specific backend
> handles this; so it would use the Updater classes described
> here. For ixfr and dynamic dns, these classes do need read access to
> existing data, so for some backends (like in-memory), i'm afraid
> this does mean 'loading' them (or sharing them with auth, if
> possible).

Conceptually, yes.  There can be several possibilities on how to do
that.

For pure DB-based data source, that would be basically
straightforward.

For in-memory data source, an expensive (in terms of memory footprint)
but straightforward way would be for both xfrin and auth to have their
own in-memory copies.  Alternatively, we could use a real DB backend
even for the "in memory" data source and have xfrin update the
underlying DB directly, while having auth make an in-memory copy of a
particular version of it.  In any case...

> Like you, I do think it should update the persistent storage first, then ping
> auth to reload if necessary. But apart from the ping, this updating should be
> done by the backend implementation, not by xfrin itself.

...right, the top level applications such as xfrin or auth should not
be aware of such level of underlying details and should only be able
to rely on the top level abstract interfaces.  I've not fully
considered details on how to do that exactly, but I believe we can
come up with a reasonable abstraction to achieve that goal.

---
JINMEI, Tatuya