Hi, I saw that the previously proposed logging library went into the review queue again, so I thought of pointing out some remarks prior the actual review. First of all, I think that a boost logging library should come up with one, and one only, way of expressing a log line. BOOST_LOG(some, kind, of, args); Now, how should the interface of BOOST_LOG(...) look like? To find that out, I'll start by explaining how I would like boost log to behave from a users point of view, for instance using boost.Asio. #define BOOST_ASIO_LOG_ENABLE #define BOOST_ASIO_LOG_MIN_LEVEL boost::log::level::debug #include <boost/asio/asio.hpp> // Insert lots of broken client code here... =) What I want to do is configure the amount of logging code that gets generated inside asio, not if the logging functionality is enabled at runtime or so. Without BOOST_ASIO_LOG_ENABLE there should be no logging code, from asio, in the executable.. I could use side by side another config for another boost library #define BOOST_SERIALIZATION_LOG_ENABLE #define BOOST_SERIALIZATION_LOG_MIN_LEVEL boost::log::level::error // only care about error logs to avoid spamming, for instance.. #include <boost/serialization.hpp> So, I've only informed the libraries that I want log to be generated, not anything about where it'll end up, or what kind of information it'll contain. The author of Asio also doesn't know what kind of information that will be generated either, but can, and should, only provide what is available from the library's point of view. // somewhere in asio code BOOST_ASIO_LOG(log::level::debug, "shutting down service.."); or, another way BOOST_ASIO_LOG_DEBUG(asio::g_log, "closing socket " << native_handle_id_); something like this is what I'm used to, but it's just for discussion. in the million ++ lines of code we have in our project we configure logs depending on system and level. That's the input required to make a log statement, the rest are details filled in by the log system itself, but it's not very interesting. a log message could automatically create the following in default config. struct msg { const char* system; //i.e. "asio" const char* source_file; const char* source_line; const char* function_name; std::string user_message; }; or it could be anything else that boosters think is portable and makes sense. My point is that libraries in boost should not deal with this, they must only learn the interface and some configuration macros of boost log (for handling the compile time enable/disable of loggin macros), and then provide the log system with the information -they have-, the rest is config details (such as log sinks and formatters). Configuring the above with a compiled library like boost serialization is an interesting task as well, that I definitely think should be addressed. could be that the flexibility decreases some in such a scenario, or it could be configued in site-config.jam or whatever. Is this along the line what boost.log has in mind, or will it be a logging library not to be used by the boost libraries themselves? Regards, Christian