[boost] thoughts on logging library

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-04-07 17:46:29

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