Greetings,

after a bit longer break we are back with proposed API.

We are still interested in contributing dynamic database API upstream.

Please, can you provide more detailed requirements for contributing code?

I would like to get information about:
- requirements to API tests
- requirements to documentation: Is enough to comment code in the same 
way as BIND?

If API will be acceptable for you, I can write some BSD-licensed sample 
driver in spirit of bind9/bin/tests/system/dlzexternal/driver.c.

Code will be polished according to 
http://bind10.isc.org/wiki/BIND9CodingGuidelines, of course.

Regards,

-- 
Petr Spacek
Software Engineer
Red Hat Czech s.r.o.

Email: pspacek@redhat.com
Phone: +420 532 294 185
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
IC: 27690016


On 06/03/2011 04:36 AM, Evan Hunt via RT wrote:
> Hi Adam,
>
> At a cursory glance this looks like quite good code, and we might indeed be
> interested in accepting it into BIND 9, as it has at least one feature we had
> hoped to support eventually (external database with the ability to serve
> DNSSEC).
>
> We can't commit it in its current form for a few reasons:  first, there are no
> tests or documentation; second, there is no sample driver we can provide as
> guidance to implementors.  (The LDAP driver you pointed to is good, but it's
> GPL, which means ISC is forbidden by corporate charter from shipping it.)
>
> We can probably help with tests and doc, but a sample driver with a BSD-
> compatible license would be a huge help, even if it only served static zones
> (such as the one in bind9/bin/tests/system/dlzexternal/driver.c).
>
> Out of curiosity, why did you decide to add a new API and new 'dynamic-db'
> configuration syntax instead of extending or improving the existing DLZ API?
> Would a merged approach be workable?  Minimizing the number of different ways to
> accomplish the same thing would be desirable, if feasible.
>
> I see a few trivial ISC code-style incompatibilities, but nothing to worry about
> on that account.  I'm planning to commit your patch to a CVS branch for further
> work, and will review the code in more detail later.