Boost logo

Boost :

From: Scott Woods (scott.suzuki_at_[hidden])
Date: 2008-02-05 19:03:12


>>
>> To raise the bar you might include requirements such as gleaning maximum
>> information from the point of logging, with minimum developer fuss and
>> delivering that information to a storage+viewing mechanism for convenient
>> post-processing and analysis, e.g.;
>>
>>
> I would say I provided that.

I suppose you can.

Here is a longer explanation of the type of circumstance that I have dealt
with and the thinking behind my comments.

a) A server product is created and is commercially successful, i.e. there
are many installations. A secondary market is created for products that
analyse the logging output of that server. These products are also
successful.
Eventually the developers of the analysis tools begin to hit limitations in
the
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
...

You might argue that your library does not prevent such output. Which would
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
more ambitious viewer can be developed, giving a richer user experience than
notepad
or nano. Analysis can be more accurate, reliable and ambitious.

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).

Again I have the perception that your library does not preclude such output
but also includes no specific solution. Which does not rule out your library
in such circumstances but it does mean that supporting work would be
required.

>> - the library doesnt appear to use the __LINE__ facillity
>>
> Actually it doesn't use it, unless you want to - if you take a look at
> the use_tags.cpp example, you'll see that the lib can actually log
> __FILE__/__LINE__, __FUNCTION__, and more.

Ah, apologies.
>
>> - how do I log the value of a variable and then search for that variable
>> by
>> name?
>>
> Not sure what you mean.
>> - how do I search for the next reference with any assurance that the same
>> name is used?
>>
> Not sure what you mwan.

Perhaps my examples of representation will give my comment more meaning?

>> - where is the default mode that just works "out of the box"
>>
>>
> How about this:
> http://torjo.com/log2/doc/html/scenarios_code.html#scenarios_code_mom
>

If I could write something like;
#include <boost/logging.hpp>

void test_mul_levels_one_logger() {
    L_ << "hello world";}

>> * What is your evaluation of the potential usefulness of the library?
>>
>> Useful. This looks after most of the needs relating to developers
>> debug output and also more permanent support output. It does not
>> appear to consider what often occurs with such output - it may be
>> the best or only record of system activity and will become the
>> focus of more complex post-processing and analysis. The library
>> does not specifically cater to such activity.
>>
>>
> Not sure what you mean. Why do you think I neglected that?
>> * Do you think the library should be accepted as a Boost library?
>> Be sure to say this explicitly so that your other comments
>> don't obscure your overall opinion.
>>
>> No. As an example of a developers debug logging facillity this is
>> one of the better ones. A Boost logging facillity should be targeted
>> slightly
>> differently. Solving the requirements of developers debugging should be a
>> side benefit of solving the wider issue of recording system activity
>> for any of the system stakeholders.
>>
>>
> Again, not sure what you mean - and please explain why my lib doesn't
> solve the above issue. Thanks.
>
> Best,
> John
>
> --
> http://John.Torjo.com -- C++ expert
> http://blog.torjo.com
> ... call me only if you want things done right
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk