Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-03-12 06:53:51

Thomas Klimpel wrote:
> Roland Bock wrote:
> > Barend Gehrels wrote:
> > [snip]
> > > However, what might happen is that if there is an
> > > attractive logging library, Boost library writers
> > > start to use it, of course.
> >
> > Why would they? I'd say logging is done by an application, not by
> > generic libraries.
>
> This is an excellent point.

While I agree with Barend's intent, a generic or standard library should not impose its own notion of logging on the application using it, even if there is a reasonably standard logging library.

If a library must communicate, as if logging, then it must provide a communication mechanism that can be hooked into the logging mechanism used by the application using it.

> As a remark a bit offtopic for the review of a logging
> library, I think the following can be said about libraries:
> Libraries have to communicate "errors", "warnings" and
> "informations" back to their "client":
>
> * The communication of "errors" is easy, just throw an exception.

Yes or, of course, return an error code or use the likes of Boost.System.  However, it is also common to log such conditions prior to throwing the exception, etc.

> * The communication of "warnings" is more challenging, since
> the library has to continue its work. So "warnings" must be
> "aggregated" as they arise and reported back when the library
> has finished its work. The "aggregation" means among others,
> that certain "warnings" are only reported and stored once
> (take "somebody included a deprecated header" warning of gcc
> as an example).

I disagree with the idea of aggregating warning information.  Often the output must appear on the output device as it occurs.

> * The communication of "information" is not necessarily
> challenging, but leads to the question which "information" is
> really interesting and should be reported. This is most
> closely related to the task of a logging library. This is
> also a broad domain, as there is such diverse "information"
> as "progress report", "work summary" and "???". What this
> information has in common is that it is not really important
> for the program logic, so it can be switched on and off via
> some sort of "verbose" flag.

The solution is for libraries that wish to communicate such information -- which would otherwise be logged by the library -- via a callback API.  Such an API is reasonably within the scope of Boost.Log (even if that turns out to not be Andrey's library).  IOW, Boost.Log can define an API and some functionality to standardize the mechanism for reporting information that would be logged, such that an application can tie that reporting into any logging system.

Thus, Boost libraries should not log via Boost.Log but should report loggable information via a Boost.Log-provided callback API that can be connected to Boost.Log or any other logging library of the application's choice.  Then, all Boost libraries that wish to report loggable information use one API for reporting and an application makes just one call to connect them all to its preferred logging library.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.