On Mon, 09 Jun 2008 11:11:31 +0200, Mojmir Svoboda
[...]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