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@torjo.com> To: <boost@lists.boost.org> 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