[Box Backup-dev] Logging

[Ben Summers]

On 24 Dec 2005, at 09:52, Martin Ebourne wrote:

> On Fri, 2005-12-23 at 22:23 +0000, Chris Wilson wrote:
>> I'd like to propose replacing all three current logging methods with
>> something like this:
>>
>> ...
>>
>> Does this seem like a reasonable plan? Does anyone have any comments,
>> questions or objections? Not answering counts as acceptance in my  
>> book :-)
>
> Sounds like a great plan to me. I was going to propose something in  
> that
> direction when converting from printf to streams. Maybe we could do  
> that
> transition in one go.

I'm OK with that kind of change, and agree that the current code is  
not ideal. Error reporting is not a strong point of Box Backup at the  
moment, which I'm afraid is a result of the project's history (it  
wasn't intended to be open sourced).

When writing the code, I tried to use

* TRACEn() for debugging output only. Errors shouldn't be reported  
through it, and it should only be useful to tell a developer what the  
code is doing.

* syslog() for messages that the user should know about.

* fprintf(stderr, ...) for non-daemon utilities to report errors the  
user should know about.

A common wrapper sounds very sensible to replace the latter two and  
remove knowledge of the execution context from the code, but the  
TRACEn() should stay. If a trace statement says something a non- 
developer might want to know about, then it could be moved to the  
logging system.

TRACEn() is a bit messy. The number of arguments is required to make  
sure it's easy to exclude them in release builds, even with annoying  
compilers, and not fill the executables with debugging strings, so  
that really should stay. But it is a bit of a mess with flags and  
attempting to do the appropriate thing. Simply feeding it into the  
new log system would sort things out nicely.

I wonder whether all the object orientation and subclassing is  
necessary, and if it could be done with a couple of functions and a  
few static variables? Simplicity is good.

>
> log4cxx is a good place to look if you need any further inspiration on
> how to do this. It does (almost?) everything you list and much more. I
> doubt Ben would want to use it directly because it would introduce  
> more
> dependencies (it itself is dependent on boost).

How did you guess? I would prefer to avoid dependencies so it's  
easier for a user to get going. Of course, if it's a 'core' thing  
which would require some serious wheel reinvention (eg OpenSSL) then  
dependencies are fine... but logging... probably not worth dragging  
in boost.

Ben