Re: [boost] Logging Library - WIP

From: Cliff Green (cliffg_at_[hidden])
Date: 2007-08-24 13:51:30

One requirement (imo) that seems to be missing or is 
under-emphasized is the following:

-- Provide a simple, light, "compilable away", 
low-dependency header / "log source" interface for middle 
layer general purpose libraries (e.g. many of the Boost 
libraries, or a third party general purpose library).

Both of the current "work in progress" logging libraries 
seem to be going full speed ahead with a relatively 
full-featured logging facility, satisfying a variety of 
needs and requirements. This is good.

But all of the example code and use cases are oriented 
towards end application usage. A large part of my software 
career has consisted of writing general purpose libraries 
and frameworks, where the end applications using my 
libraries run in a variety of environments. This is also 
true of most of the Boost libraries. So the "BOOST_LOG" 
interface should be usable in any library (including a few 
in Boost where it would be invaluable - e.g. Asio, or 
Serialization).

Since a library / function using "BOOST_LOG" might be used 
in a single-threaded app, or might be used in debugging 
only (where in release mode no logging is desired), or 
might be used where high performance and low overhead is 
an absolute priority, or might be used in a non-networked 
environment, or might be used where "memory only" logging 
is available (i.e. there's not a file system available), 
"BOOST_LOG" (or its equivalent) should be:

1. Capable of being completely compiled away.
2. Bring in the absolute minimum set of dependencies.
3. Be completely "sink agnostic" - i.e. the output of the 
logging can be configured to go to any of a number of 
potential sinks, including no sinks.
4. Be very performant - if logging is present but no sinks 
are turned on, the overhead should be very small (ideally 
cost no more than an if statement or two). Mutex locking 
for multi-threading should not be performed unless logging 
in a multi-threaded environment (or a threaded sink / 
service) is turned on.

Configuration of the logging environment - e.g. which 
sinks are turned on, which optional attributes are turned 
on, etc, should be a different set / layer of Logging 
functionality, separate from the "BOOST_LOG" / log source 
client interface. The end application (or some higher 
library layer) controls this aspect.

The logging implementations so far seem to be "code only" 
instead of concentrating on the rationale, use cases, and 
client interfaces. I think there's danger of another "log 
library rejection" without some "stepping back and 
re-thinking" (and I've forgotten most of the original log 
library review comments - I should go back and re-read, 
since I'm sure I'm repeating comments already said).

I'll be happy to add any of these comments to the Wiki 
Boost Log area - let me know (I can also assist with 
library requirements and design - I've designed and 
developed at least two logging libraries in past 
projects).

Cliff