|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-12-20 12:03:30
>> I see the central concepts as:
>>
>> Entry (or Message): the set of information that makes up a
>> single message to log. Might include a "level" (e.g. debug,
>> info, warning, error), a "category" (e.g. arguments,
>> program_flow, etc), a "keyword" (e.g. "Network", "UI", "Disk
>> Cache", etc) and of course a text string.
>
> Could be more or it could be less in specific situations. But other than
> that I agree with you.
>
>> Filter: determines whether or not an Entry should be logged.
>> Probably implemented as a relatively simple functor.
>> Sink: ultimate destination for Entries. Implementations for
>> wirting to files, system log facilities, etc can be provided.
>> Log: provides logging methods. Implements the Filter concept
>> and contains zero or more Sinks which are the targets of
>> Entries for which the Filter returns true.
>
> I aggree with you on a conceptual level. However, the Filter concept
> shouldn't be part of, IMO, the logger. Or if it is, at least, there
> should be an alternative interface in the logger, or possibly, the
> filtering concept should be very simple if I don't want entry keywords
> and such.
> Fundementally, I think that writing log statements and filtering log
> statements are two different and orthogonal concepts. Filtering is an
> efficiency decision at the conceptual level. With that I mean if we had
> infinite computing power (which we don't) filtering wouldn't be
> necessary at all when sending log entries to sinks. Filtering is however
> something the target audience does when looking for, or at, log
> statements. That is, with infinite computing power, the filtering
> mechanism could be done at the time when administrators/programmers are
> looking/searching logs.
>
> But since we don't have infinite computing power, log entries need to be
> filter before sending them to sinks (I suppose one could argue that
> there are other reasons for filtering before sending entries to sinks;
> but I don't see a difference). So the interface for enabling/disabling
> log entries should be a fundemental concept to a logging library and
> obviously as well designed as the actual log entry interface.
>
> Especially, wether to send a log entry to a sink should incur minimal
> overhead, or else risk efficiency even if the log statement are not sent
> to the sinks. This is especially true if programers use many log
> statements.
>
> IMO at the most fundemental layer, a logger is either enabled or
> disabled. If it is enabled, log entries are sent to its attached sinks.
> Filtering should be implemented on top of loggers. The filtering concept
> determines wether to send the log entry to the logger or not.
Filterring is indeed is in theory is orthogonal to formatting. With two
simple but very important exceptions:
1. The data that used for filterring is as frequently needed for formatting
and we do not want to collect data twice. I think that Filter concept should
be extended (or another concept needs to be introduced: Non-Filterring Entry
component).
2. Log need to know entry data components by name to be able to configure
formatting properly
While designing one needs to keep in mind following points:
1. There are entry components that are used for filterring. These should be
collected before the filterring stage begins.
2. There are entry components that are not used for filterring. These should
be collected before the formatting stage begins (pre/post filterring is not
mandated).
Any of the components we talked previosly - level, file, line keyword,
thread id - could, depending on users, belong to either group.
3. We do not want to collect data for filterring and formatting twice.
4. Log should be able to refer to the entry components by name for
configuration purposes. I want to be able to configure log/sink with config
string: "prefix=thread_id time file(line):"
5. Sone entry components need external source for initialization (file,
line, level etc), some doesn't (thread id, time).
Gennadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk