[Box Backup-dev] Logging

Ben Summers boxbackup-dev@fluffy.co.uk
Sun, 25 Dec 2005 18:27:32 +0000


On 25 Dec 2005, at 01:10, Chris Wilson wrote:

> Hi Ben,
>
> On Sat, 24 Dec 2005, Ben Summers wrote:
>
>> 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'd like to be able to turn tracing on without recompiling. Is the  
> space saving, and tiny performance gain of excluding these  
> messages, really worth the debugging hassle?

I would want to exclude them in my release builds.

Perhaps we should make each bit configurable at ./configure time,  
with a default set for debug and release builds which makes sense?  
Then people building binaries can choose the options they actually  
want, if they don't agree with me/the defaults. I don't think there's  
much extra work, if any, to accommodate everyone.

>
>> 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.
>
> I like simplicity too, but I also like object orientation and  
> polymorphism. I'd like to create a framework that could in  
> principle support other kinds of logging, such as writing a log  
> file or sending messages over the network (to the backup server  
> administrator or system support staff).

Unless you make a wonderful framework which supports user added  
logging without having to recompile, then it might be overly  
complicating things. The time might be better spent developing and  
debugging other stuff, and simplicity makes things easier to get  
finished.

On the other hand, a lovely logging system is a good thing to have. I  
have no strong feelings on this, just a waryness of potential over- 
engineering.

Ben