Re: [boost] A meta-proposal for logging

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.

Michael