Re: [boost] Review of Logging library begins today February 4th

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-02-06 03:21:52

Hi John,

Paused for food. A picnic with friends over the local surf break, on a balmy
night in the South Pacific. Ah but back to more important things ;-)

----- Original Message ----- 
From: "John Torjo" <john.groups_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, February 06, 2008 4:06 PM
Subject: Re: [boost] Review of Logging library begins today February 4th

>
>> the log file. Either useful data is buried (cannot be extracted) or
>> inconsistently represented.
>>
>> Some examples of representation;
>>
>> After completion there were 3 leftovers and ...
>> After completion there were <3> leftovers and ...
>> After completion there were <3!unsigned int> leftovers and ...
>> After completion there were <3!unsigned int/matching_profile> leftovers 
>> and
>>
> The last representation : what does "/matching_profile" mean?

It was intended to be an example of an encoded variable reference. The
last component being the supplied variable name.

> Based on what you've just printed above, how would you see the 3 value
> above? Like this:
> unsigned int leftovers_count;
>

No, like this (choice of identifier not helpful);

unsigned int matching_profile;

> If so, the first 3 representations would be rather easy to implement.
>> ...
>>
>> You might argue that your library does not prevent such output. Which 
>> would
>>
> Indeed so ;)
>
>> be true. What I am suggesting is that a Boost logging library should 
>> provide
>> explicit solutions to such issues. With such formalizations in place a 
>> much
>>
> Actually, I would expect a Boost Format library to handle those issues.
>> more ambitious viewer can be developed, giving a richer user experience 
>> than
>> notepad
>> or nano. Analysis can be more accurate, reliable and ambitious.
>>
> I'm all for that. However, I'd rather have a layer on top of Boost
> Logging, or completely separated, to handle your specific case, than to
> force the users onto the above scenario.
>> b) A customer requires a low-cost, low-tech, highly robust audit trail of
>> all activity on their system. It is decided to log all events into text
>> files. Each
>> event involves a time, a unique identifier and a list of zero or more
>> runtime
>> values (i.e. parameters).
>>
>>
> About "event involving a time, unique id, list of ..." - could we be
> talking about tags?
> I believe those should actually be what you want:
> http://torjo.com/log2/doc/html/namespaceboost_1_1logging_1_1tag.html
>>

Think it's fair to say no. While technically I suspect tags could be applied
to the problem at best it would be unwieldy.

The crucial piece seemed to be the declaration of the tags macro where
the log message is decorated with information from the runtime context.
This might be on a per-module or global basis.

I'm guessing that in my circumstance there would be a set of declared tags 
for each
event type.

Cheers,
Scott