Re: [boost] [Review] Boost.Logging: formal review

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-12-19 10:41:22

On 12/19/05, Richard Glanmark <Richard.Glanmark_at_[hidden]> wrote:
>
>
> > All in all I prefer message not be inside brackets. It looks
> > much more natural and I don't see any theoretical problens to
> > get the same performance. But I also believe that macro
> > shouldn't be a primary interface.
> > So if you prefer message inside the breakets - it's your choice.
>
> However, there is one additional benefit of placing the message inside
> brackets. One can remove the log statement in a build. Other than that,
> I guess its style preferences.

I personally prefer the all-enclosed macro style for this reason as well as
others.  But I think one of Gennadiy's points is that the primary interface
to the Log should not be defined in terms of macros.  A standard set of
macros can be provided by the Boost.Log implementation for the sake of
convenience and casual use.  But there should be a well documented public
interface that users with more complex requirements can use to write their own
logging macros, in whichever style they prefer.

> My position that library should be configurable by any class
> > satisfying Filter concept.
> > This particular filters could probably be supplied by the
> > library as an example and as most widely useful.
> >
> > > My proposed solution is to basically let loggers be somewhat entry
> > > (Gennadiy's definition above) unaware. Instead, let the developer be
> >
> > I do not see how it's possible. IMO framework should employ
> > some MPL magic and construct proper entry structure based on
> > set of Filters passed as template policy parameters.
> >
> > > entry aware. By that I mean that the developer should log messages
> > > that belong to a specific entry category/level to a
> > specific logger.
> > > For
> >
> > This is never be acceptable IMO. Even with 3 filters, each
> > ahving 5 possible values you looking into 125 different loggers.
>
>
> Support for log functions on top of a basic framework solution is needed
> to alleviate this problem. I wouldn't mind that the library provides log
> funtions that take various filter functions or predicates to determine
> wether to send a log statement to a logger. In this case, the logger
> would be enabled and the log filter function would send log statements
> to the logger if the log statement meets some criteria.
>
> Still, the underlying logger framework would be the same; logger object
> should still be enabled or disabled/enabled, there would still be a few
> different logger objects for different levels and possible other user
> defined criteria.

I don't think it makes sense to require a user to have separate loggers to
handle e.g. DEBUG, WARNING, and ERROR levels.  I also don't think it makes
sense to require separate logs for different logging keywords (I think thats
the term Gennadiy used).  The user may use separate loggers for each of
these separate logical channels, but it should not be a requirement.

IMO it is very important for an administrator/programmer of a system to
> be able to enable/disable logs, know what loggers and appenders exists
> and be able to configure said entities.

But if the programmer has to provide a separate logger for each logging
level and conceptual channel of log information, each of which is configured
independently, isn't this management problem far worse?

If filter is only done on a per log statement, how do you even know as a
> administrator of a system what log filters exists? Which filter criteria
> should be enabled and which filter criteria should be disabled?
>

Can you expound a bit on what you mean by this?

If all log statements are sent to one logger object, the logger object
> becomes a monolith of functionality and complexity. Runtime performance
> might degrade considerable if various filters is to be checked, not only
> if the log statements should be logged, but also if one wants to send
> log statements to different appenders/sinks/destinations.

I don't think the functional area is all that large.  I see the central
concepts as:

Entry (or Message): the set of information that makes up a single message to
log.  Might include a "level" (e.g. debug, info, warning, error), a
"category" (e.g. arguments, program_flow, etc), a "keyword" (e.g. "Network",
"UI", "Disk Cache", etc) and of course a text string.
Filter: determines whether or not an Entry should be logged.  Probably
implemented as a relatively simple functor.
Sink: ultimate destination for Entries.  Implementations for wirting to
files, system log facilities, etc can be provided.
Log: provides logging methods.  Implements the Filter concept and contains
zero or more Sinks which are the targets of Entries for which the Filter
returns true.

The basic implementation of all of these should be relatively simple.  I
think the bulk of the complexity will come in writing specific Sinks that
interface with various system-specific APIs, and perhaps in a Configuration
class which can be used to initialize a Log and load it with a set of Sinks
at runtime.  And perhaps UNICODE/I18N issues.

Also quoting from Gennadiy's review of John's submission (sorry to keep
pointing to your review, Gennadiy, but it is as always a very astute one):

Log may have multiple appenders attached (BTW - I very much prefer term used
> by iostreams library - sink). what if I want different entry
> formatting/prefixing/filtering in different outputs. I may have
> errors_output which contains only errors. I may have end_user_log that
> contains only major information for end user with detailed time and date of
> the entry.
>

I think the idea of the Log having multiple Sinks, each of which may perform
custom formatting on the output and perhaps even ignore some Entries is
important here.  This says to me that the Log concept is a very simple one:
simply check the Filter and (if true) forward on to the Sinks.  No modifiers
happen here.  The Sinks may themselves do further Filtering (e.g. in the
case of the error_log above) but they receive the Entries exactly as the
user passed them to the Logger.

I've been sketching up a very simple implementation of some of these ideas
in my spare time.  Is there interest in fleshing these ideas out more fully
on or off-list?

--
Caleb Epstein
caleb dot epstein at gmail dot com