backend abstraction layer

[Erik Rozendaal]

Paul G wrote:

> this is a little less robust than i'd like. while i'm a big fan of "The Unix
> Way", shellscripts that take 5 minutes to write and save hours of c coding
> etc, i'd rather have something closer inegrated in a production environment.
> with that said, i might well end up doing this because i'm lazy.

Another advantage of the "generate a .zone file from the database" 
approach is that it is easy to use with any other nameserver, because 
they all(?) support .zone files.

> right. adding an is_dynamic flag to a per zone structure and implementing
> atomic updates thtough ipc would work for this, simplistically speaking,
> yes?

I'm not sure if I completely understand you here.  But I suppose if you 
used such a flag and reimplemented/modified the functions specified in 
namedb.h you'd be able to get most of NSD to work with another backend.

But the API specified in namedb.h might not be a very good "fit" for a 
dynamic SQL based backend.

> understood. my concern is my ability to maintain a patch that would be as
> intrusive as this one if it does not get accepted into the main codebase. i
> am still on the fence as to whether i'm going to be doing this and i am
> definitely seriously considering the simpler, more hackish solution as well.

It is hard to predict the amount of modifications necessary for your 
requirements.  If the changes are limited to some internal API changes 
that do not complicate the rest of NSD but make implementing dynamic 
backends easier those changes will be accepted.

But support for any kind of specific dynamic or SQL backend will most 
likely have to remain a separate patch or plugin.

Erik