Re: [boost] [logging] Interest check on logging library.

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 
> message?
> 
> 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?