CC: Petr Spacek <pspacek@redhat.com>
MIME-Version: 1.0
In-Reply-To: <519CC58E.8060601@redhat.com>
References: <4F703764.9080300@redhat.com> <519CC58E.8060601@redhat.com>
Message-ID: <519CCD74.50002@redhat.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [ISC-Bugs #24733] [PATCH] New dynamic_db database interface for BIND
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
Date: Wed, 22 May 2013 15:51:48 +0200
To: bind-suggest@isc.org
Content-Transfer-Encoding: 8bit
From: Tomas Hozza <thozza@redhat.com>
RT-Message-ID: <rt-3.8.6-32010-1369230725-1864.24733-0-0@isc.org>
Content-Length: 3474

Hello.

As a new maintainer of BIND at Red Hat I would like to ask you how
things look with our "old" initiative to add a new dynamic_db database
interface into BIND9.

It has been a long time since we heard anything from ISC regarding this
matter.

I want to point out that we are still interested in contributing this
dynamic database API upstream. Therefore I would like to ask you for
some feedback what has to be done from our side to get our code into
BIND.

I'm including previous communication regarding this matter between ISC
engineer Evan Hunt and previous Red Hat BIND maintainer Adam Tkac and
also last email set by Red Hat engineer Petr Spacek. Unfortunately we
didn't get any answer on it last time, but really hope we will get some
this time.

We would really like to finish our effort and finally get things done.

Thank you in advance for your answer.


Regards,

Tomas Hozza

> -------- Original Message --------
> Subject: Re: [ISC-Bugs #24733] [PATCH] New dynamic_db database interface
> for BIND
> Date: Mon, 26 Mar 2012 11:31:16 +0200
> From: Petr Spacek <pspacek@redhat.com>
> To: bind-suggest@isc.org
> CC: atkac@redhat.com
> 
> 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.