Re: [boost] A meta-proposal for logging

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

Hello Niko,

Friday, April 6, 2007, 2:12:41 PM, you wrote:

> Hello,

> If I just wanna log a timestamp and some text for the admin of my
> webserver to read, why would I want things like thread name and scope
> stack in my beeing updated and filled in all the time?

Ok, I agree we should provide a global attribute set.

>> Well, there's no point to log an empty record. At least message text
>> should be present in any record, don't you think so?
>>   
> I don't think so. How about I define an new attribute for my logger
> which is some object that I want to convert to text and format lazily?

I don't see how is it different from message text. You just output
your object to the logger stream and see it in the log.

> I think we should leave it as general and extensible as possible, without
> loosing simplicity.

Agreed.

>> Although, if there's a strong anticipation against a set of
>> mandatory attributes, I would propose to introduce three attribute
>> sets instead of two, as I was considering before:
>> - Logger-associated set. Each record, collected from the logger has
>> these.
>> - Thread-associated set. All records made in the thread have them.
>> - Global. All records throughout the app include attributes from this
>> set.
>>
>> All three sets would be alterable in runtime.
>>   
> Agreed, but should it be to have these or should they be mandatory?

What do you mean? The attribute set may be empty, so every attribute
is optional (aside message text, which is under discussion).

> Again I think it should be easy to use such sets, but there should be no
> mandatory list. Maybe I want to define my own set, say for a program
> module or something. Or are we getting to generic and complex here?

I think, there will be no restriction on constructing attributes and
storing them in STL-compatible containers. Although the library itself
will use only those three listed above, so user will have to add his
attributes to one of these if he actually wants to log them.

>> But still, I am convinced that the message text should always be
>> there. This fact in conjunction with its lazy construction, actually,
>> makes it so special that it may be not an attribute at all.
>> And as a side note, this will make it impossible to filter by the
>> message text just because it won't be available at the time of
>> filtering. Can we live with that?
>>
>>   
> I think we shouldn't. See above. Filtering by text should be possible to
> implement, but IMO not be directly provided by the library.

Hm. Let's put in this way. It may be possible but not though the
regular filtering mechanism. A sink may actually decide wether to
write the message to the output or not after the regular filtering was
applied and formatting was made. This makes the difference between the
message text and other attributes even greater.

Otherwise I don't quite realize how to implement it in a user-friendly
way. I wouldn't want to lambdify each logging record.

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