Re: [Boost-users] yet another logging library

From: Boris (boriss_at_[hidden])
Date: 2008-06-09 07:11:29

On Mon, 09 Jun 2008 11:11:31 +0200, Mojmir Svoboda  
<mojmir.svoboda_at_[hidden]> wrote:

> [...]this 'going public' thingy is not really 'i do want write logging
> library right here right now' but more like 'heey, i have this in my
> drawer and i can make it better than the first version, but does
> anybody want it?' because i can surely find myself another toy elsewhere.

While I'm not making the final decision which library is going to be the  
Boost logging library it might make more sense then to discuss what you  
think would make your library better than the first version? If the ideas  
are then implemented in John's or your library is secondary? As John's  
libary is not finished anyway and as I for example also like some things  
to be changed new ideas are surely appreciated.

> [...]this is not my priority right now. now i am working with something
> called buffer manager and something called sink. buffer manager gives me
> space to write (if any.. of course message will be dropped if there is
> not) and sink takes ownership of full buffer and does something very
> blackboxish then: there could be a stdout, stderr, socket with low
> priority thread, small black hole or a hidden schrodinger's cat
> reading and not reading the messages at the same time ;)

John's library has a concept called destination which sounds like your  
sink. There is another concept called formatter which, well, formats  
messages before they are written to the destination. I'm not sure if there  
is any buffer involved (there is a cache though which can be activated and  
deactivated at any time if I'm not wrong).

In my opinion one of the most important questions is what else can a Boost  
logging library offer than what we can do today with:

clog << "Logging ...";

As we can easily redirect clog or replace it with another stream object  
where we can control the buffer there must be some added value?

Boris