From: Andrey Semashev (andysem_at_[hidden])
Date: 2007-04-05 14:38:32
Thursday, April 5, 2007, 12:27:39 AM, you wrote:
>> 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
> I think that defining a mandatory set of attributes is going to rub a
> lot of users (me included) the wrong way. My sense is that we will be
> better served by a system that let's you dynamically (and easily!)
> associate attributes with a message. Moreover, it needs to be simple
> to do that on a global or per entity (e.g. channel, sink, message)
> basis. We could provide the kinds of formatters you describe with
> the library as they have obvious general utility.
> 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.
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.
>> 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.
> I agree with this completely, except that (per above) it should apply
> to all attributes :)
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?
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
- Thread-associated set. All records made in the thread have them.
- Global. All records throughout the app include attributes from this
All three sets would be alterable in runtime.
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).
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?
-- Best regards, Andrey mailto:andysem_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk