[bind10-dev] Planning for next sprint - input required

[Jeremy C. Reed]

On Tue, 30 Nov 2010, Stephen Morris wrote:

> >> I agree, and in case you were not aware of it there's already a python
> >> version of logging framework for BIND 10 (src/lib/python/isc/log/).

It is called a "dummy". I don't think it is planned to be used. Even all 
the uses of it would be renamed at the minimum.

> > Currently, the python logging framework only used by Xfrout module, there is
> > a need to apply logging in all other python modules.
> 
> Agreed.
> 
> > 
> >> For C++, there's a proposal of logging framework for boost
> >> (http://boost-log.sourceforge.net/), but it doesn't seem to be merged
> >> to the official boost libraries.  It also requires compiled library of
> >> boost (according to the documentation), so it's probably not suitable
> >> for us.  We could port BIND 9's logging framework, although this may
> >> be one of the areas where we don't like to take an in-house approach.
> > 
> > I am not sure if we should port BIND 9's logging framework, but at least
> > there are so many sexy features that we can learn from.

See http://bind10.isc.org/wiki/Bind9Logging

> There are many C++ logging frameworks.  Ones I've had a quick look at are:
> 
> Google log (http://code.google.com/p/google-glog)

BSD style license

> Log4cpp (http://log4cpp.sourceforge.net)

LGPL

> Log4cplus (http://log4cplus.sourceforge.net)

Simplified BSD license (or optionally Apache 2.0 license)

> Log4cxx (http://logging.apache.org)

Apache 2.0 license

> Pantheios (http://pantheios.sourceforge.net)

BSD style license

> Boost (http://boost-log.sourceforge.net)

Boost Software License 1.0 (it is fine)

We are repeating some of this discussion again.

> I think we should define our own requirements first, then make a 
> selection.

A task for a sprint?

> To minimise the dependency on external software we might want to 
> define our own API and implement it in terms of a chosen package - 
> that will make it simpler to switch if we want to do so in the future.

Yes.