* Boris
The reason why I was mentioning Windows Event Logging and Event Tracing
this is it? http://oreilly.com/catalog/winlog/chapter/ch02.html
before was that I think a Boost Logging library should somehow support operating-system specific logging standards (or at least make it easy to support them).
or like syslog? i tried it few times but was rather disappointed by the performance. this is more like 'hey, something critical happened' than for regular full-blown logging. i wonder if it's better on any platform. of course i will have a look at these, but i do not see any problem as long as the two interfaces are somehow compatible with mine. i know syslog, and it can certainly be integrated into it.
If a Boost Logging library was just a more efficient implementation of clog, maybe with a built-in mutex for thread-safety, it doesn't really deserve to be called a Boost library? :)
it depends. we can always make things complex, but logging is not in most cases.
For example the idea of a destination concept in John's library is already nice as a destination can be more than a stream (and I think there is even a destination class for syslog in John's code somewhere although I don't see it in the documentation).
well destination==sink, formatter==filter and that's it :) we both made the same design decision as it seems. mojmir