MIME-Version: 1.0 In-Reply-To: X-Mailer: MIME-tools 5.428 (Entity 5.428) Content-Disposition: inline References: <4DE76CE2.3050600@redhat.com> <20110602142908.GA89544@isc.org> Content-Type: text/plain; charset="UTF-8" Message-ID: Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 RT-Send-CC: Content-Length: 1290 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.