Re: [boost] A meta-proposal for logging

From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-04 15:49:50

Hello Michael,

Wednesday, April 4, 2007, 5:31:29 PM, you wrote:

> Andrey Semashev wrote:
>>
>> 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.

I see. I guess now I'm beginning to understand what channels are meant
for. The channel appears to be yet another attribute which defines the
"class" of the log record (i.e. an access log, debug trace, etc.).

Seems to me we have to fix the set of mandatory attributes that every
log record should always have and leave space for optional attributes
(channels go here). I see these attributes as mandatory:
- record number (increments for each record collected)
- record date and time
- thread name (if not set - thread id)
- scope stack
- severity level
- message text

As for optional attributes I think, it's better to leave them on
user's behalf since it's too difficult to figure out the correct set
of them and implement suitable interface to operate them in the
unified and convenient way. But, surely, the library should leave an
easy way to implement them.

-- 
Best regards,
 Andrey                            mailto:andysem_at_[hidden]