From: Michael Lacher (michael.lacher_at_[hidden])
Date: 2007-04-04 09:31:29
Andrey Semashev wrote:
> Hello Austin,
> Tuesday, April 3, 2007, 10:55:49 PM, you wrote:
>>> 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.
>> You're probably going to find yourself in the minority here. In many
>> instances, a log might be the only way communicate an error to the
>> user; consider, say, a webserver or NFS lock daemon. More generally, I
>> think that a generally useful logging system will be able to handle
>> arbitrary logging and won't be concerned with domains or specific
>> usage patterns.
> I agree with Austin. I think, the "user" word is what confused you.
> The "user" here may be a system administrator or a technical support
> service specialist, for example. Such users have enough knowledge
> about the application that produced the log, so they are able to read
> it and figure out the problem. Though they are not interested in the
> internals of the application which only developer knows (i.e. they
> wouldn't understand what "i = 10, too bad :(" log record means).
> On the other hand, I believe such functionality may be easily achieved
> with proper filtering and providing separate sinks for these types of
> output. Michael, do you agree with me?
I agree with your general description, but i am not sure seperate sinks
are a good idea (even if they provide a way to do it). The problem is
that often temporal coherence and the sequence of log messages is
important to determine the root of a problem. For example: the debug
message that a socket read blocked unexpectely is much more informative
if i can view it in the context of log statements telling me wich client
connected/disconnected. If one lands in a debug file and the other in
the access log then i will need to take special steps to view them in
the correct order which is undesirable i think.
The project I am currently working on has many seperate daemon programs
(possibly running on different machines too), so i specifically added
networked logging with a single sink, just to be able to view all the
log messages in their natural order.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk