bundy

On 30.04.2014, 20:54, Shane Kerr wrote:
>> Regarding libdns++, I think the ideal way is to unify the effort,
>> rather than maintaining the each branch of the fork.  libdns++ was
>> intended to be as standalone as possible from the beginning, and
>> is generally less dependent on other part of BIND 10/Bundy.  Maybe we
>> should make it even more so, e.g., allowing it to be buildable
>> separately.  And, then, ideally, Kea could use it as a third party
>> library just like Boost or log4cplus, and ISC developers could
>> directly contribute to the Bundy version of libdns++ as they find bugs
>> or need for enhancement.
> 
> I kind of like this idea. Making anything standalone that can be
> standalone seems like a good idea. :)
> 
> Should we go ahead and pull libdns++ out of the Bundy repository and
> put it somewhere on its own then? Perhaps still under the bundy-dns
> GitHub organization. I realize this would mean some work on both the
> libdns++ and rest of Bundy, but my guess is that it would not be *too*
> much work...
I'm in favor of this approach as well. One particular thing that would
make it also appealing for Kea is the capability to build just its C++
part, without python wrappers. We wouldn't be able to take advantage of
it in the next couple months (challenging schedule as usual), but after
that it seems quite attractive. The alternative - to maintain our own
fork of it - is not.

Tomek