[bind10-dev] writable datasources 3/3; API proposal

Jelte Jansen jelte at isc.org
Mon Jun 21 13:27:22 UTC 2010

Hash: SHA1

On 05/17/2010 10:09 AM, zhanglikun wrote:
> Some minor suggestions.
>>     /**
>>      * Add an RRset to a zone. If the RRset already exists, the
>>      * RRs in this set are added to it.
>>     virtual Result addRRset(isc::dns::Name* zonename, isc::dns::RRset&
>> rrset) = 0;
> Divide the API AddRRset() into AddRRset() and AddRR() to avoid unnecessary
> duplication check, It's useful when we replace the old rrset with the new
> one.
> AddRRset(): Don't check duplicated records, add rrset directly.
> AddRR(): Do record duplication check.
> Or it can be done by adding a parameter
> addRRset(isc::dns::Name* zonename, isc::dns::RRset&, rrset, bool
> duplication_check) = 0;

having two separate ones is probably better, i'm think we can probably have a
default implementation for the 'smart' one.

>>     virtual Result doIXFR(isc::dns::Message *msg);
>>     virtual Result doUpdate(isc::dns::Message *msg);
> Should these two APIs provided by datasource? I think it should be down by
> update and XFR module.

I think they should (though they could have other names, but this is essentially
what they would do); unless i'm wrong in my assumption that these could have a
lot of benefit from knowing the internal structure. Similar to doQuery; we can
have a general high-level one and datasources may override them if they need or
want to do backend-specific things. If my assumption is wrong then they should
indeed be in xfr/update/load/whatever.

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


More information about the bind10-dev mailing list