[bind10-dev] Ruminations on difference normalization (#1456)

[Michal 'vorner' Vaner]

Hello

On Wed, Dec 14, 2011 at 05:18:10PM +0100, Jelte Jansen wrote:
> pro:
> - - any tool or module that uses the updater API can do it whilst
> supporting IXFR-out, without any requirements whatsoever (on the
> 'user's' side that is, naturally the datasource would need to support
> it, etc.). Immediate thoughts would be b10-ddns (and with the
> from-differences approach, AXFR-in and b10-loadzone as well). But also
> whatever we will build for auto-dnssec later, and dhcp-updates, and any
> other cool module someone comes up with later.

And, maybe, if done right, we wouldn't need to keep the updates in memory, but
apply the to the DB, with one ID for the add-ones, another ID (bigger) for the
remove one and then add the SOA records. The database doesn't have to be filled
in order ;-).

> con:
> 
> - - this may make the ZoneUpdater smarter than it necessarily needs to be.
> It already has a few options that change its behaviour and this would
> add at least two more (and maybe more).
> - - the current zoneupdater is also database-api only so depending on what
> internal structure we make for this we may find that the 'direct'
> implementations (i.e. in-memory) need a bit more work as well, when we
> add this there.

I don't believe the in-memory will have it's own updater, it would delegate it
to the updater of underlying DB or something.

Anyway, I'd like to see this functionality separated somehow from the
backend-dependant code, so if someone writes a datasource, he needs to code the
dumb one only, not to duplicate the smart one. Could this smartness be in the
base class of updater, or something?

With regards

-- 
Never underestimate the bandwidth of a station wagon full of HDDs.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20111215/417e4bd7/attachment.bin>