From: Michael Lacher (michael.lacher_at_[hidden])
Date: 2007-04-04 09:06:16
>> Since I'm interested in having such a library in Boost, I'd be happy
>> to participate.
> It's what you did and you did well! Thank you!
> - Nonetheless, I see a very interesting contribution from Michael
> Lacher. I'm not sure the mailing list is the right place to discuss
> them, but I don't see any discussion page on the wiki.
> Concerning req id 3: Michael, I don't really get this statement. I think
> it's really to the library user (programmer) to decide which log shall
> be present or not. He's in charge of filtering the logs following the
> compilation configuration (debug or release). I don't think the library
> shall manage this by itself. Or maybe I did not get your point at all!
I agree that it is, and it is actually a rather trivial task to write
macros to remove the offending log messages. I just think that it would
be nice if a logging library would already come with convenience macros
that have this in mind.
> General Thoughts, third bullet:
> You say:
> "Logging: print log messages useful for the program user. They are
> needed to understand unexpected conditions during usage like: "file xyz
> not found", "directory baz is not readable".
> I can't disagree more with this. IMO, logging is not at all a way to
> give information to the program user. In my mind, a logging library is
> intended only for debugging, journaling, auditing and performance
> measuring. Not a way to display error message or waiting message to the
> user. In my mind, these are totally different things. Please someone,
> give his POV on this, I think this is a major disagreement.
Maybe my examples are badly chosen. When i say logging i probably ment
what you describe as journaling (like a web server access log). To stick
with the example of a webserver: while debugging i might be interested
in very fine grained debug messages, without having to sift through
hundreds of lines of access log telling me when i connected and which ip
i used over and over again.
I cannot seem the channels you mention below, but if i understand
correctly this is probably exactly what i meant:
* Conceptually log messages are associated to one or more channels, and
by modifying the channel threshold you can specify if you are more or
less interested in messages of this kind.
* Each sink can specify a filter/threshold to define how
suitable/desired output of the given verbosity is for this specific sink.
It would even be possible to filter/classify log messages in channels by
their scope, but i think this is the point where the effort off
configuring it all might outweigh the actual gain.
> - Besides, Caleb Epstein propose the definition of channel as:
> Multiple named channels each with configurable "threshold" (e.g. error,
> warning, debug, etc)
> Caleb, would you mind add a definition of channel on the wiki
> and maybe add some requirements on this?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk