Boost logo

Boost :

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


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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at