Re: [boost] A meta-proposal for logging

From: Niko Demmel (niko.demmel_at_[hidden])
Date: 2007-04-06 06:12:41

Hello,

I've been following this discussion for a while.
>
>> My main point, though, is that no mandated set of attributes will
>> please everyone and may well be a huge point of contention.
>>     
>
> But how would these attributes harm somebody? They are meant to be
> silently filled and updated by the library automatically, so they are,
> in fact, a guarantee to user, not the requirement.
>   
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?
> The another reason I've chosen these attributes is that they are
> either cumbersome to fill at user level or are constant all the time.
> See record number for example - a user should maintain the global
> counter and update it on every log record himself.
>
>   
They could still be provided by the library as default values for, say,
debug type logging, or easily be added by the user if desired.
> 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
think we should leave it as general and extensible as possible, without
loosing simplicity.
> 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?
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?
> And the attribute concept should be extended too. For now I was
> thinking of it as of a value container. To make it suitable for things
> like record counter or record time it should be thought of like a
> value generator (which, of course, may "generate" the constant value
> to emulate value container case).
>   
Sounds good.
> 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.

Just some thoughts.
Klaus