$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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