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