Subject: Re: [boost] [logging] Interest check on logging library.
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-12-29 11:26:03
Jason Wagner wrote:
> One of the projects I deal with can generate several hundred MB of logs
> over the course of a day if we have logging cranked up. We log both as
> an light audit trail and a debugging tool. Dealing with that much
> information can become rather difficult. There are a few things that
> come to mind that I would change in it:
> 1) When reading the code, logging should scan like a comments-- they
> should be readable and informative but ignorable. A lot of logic,
> conditionals, or even excessive formatting distracts from figuring out
> what a function actually does. Severity (debug, warning, error, etc) is
> only one dimension, though the most common. If I add new dimensions,
> how much does that affect complexity of the conditionals? What are the
> chances of mistyping one of the conditionals and not getting a logging
> 2) The logging output needs to be well formatted, readable, and broken
> up into manageable pieces. Imagine getting a packet or request in, then
> having to dump it. Does it show up as one or two records? Does it end
> up on a 500 character wide line? How much overhead should one add to
> the site of the logging call to format this? If I split my files into
> an log file that contains everything and an audit file that only
> contains some, should the formatting be the same? What if I want to
> merge them at a later time, do I need to edit everything and recompile?
> What if I want to change output and direction at runtime? Do I think of
> all of that in the function, or do I configure the logging and just let
> it fly?
> The former implies that there should be an abstraction around the logic
> of whether a record gets logged. The latter implies an abstraction
> around formatting and how to determine the destination of the record.
> That and a few extra bows is the extent of what I'm trying to do.
Sorry, couldn't resist. I think, my library fits these requirements
quite well. Why would you start your own implementation from scratch? Is
there something that doesn't suit you in my implementation?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk