New logging design (was Re: [Box Backup-dev] COMMIT r285 - box/chris)

Martin Ebourne boxbackup-dev at fluffy.co.uk
Thu Jan 5 20:40:47 GMT 2006


On Thu, 2006-01-05 at 19:58 +0000, Ben Summers wrote:
> DEBUG might be a better description than TRACE, now that it's in a  
> generic logging system.

I agree.

> Will there be a configure time option to compile in all DEBUG/TRACE  
> loggings stuff, even in the release build?

That would be useful.

> Also, on a larger project I worked on, it was handy to have TRACEUSER  
> macros which only emitted the line if the user compiling the project  
> was as specified in the first argument.

I've no idea on what sort of project that was, but I could see that
being useful in a commercial 'team' setting, but think that would not be
so ideal for open source.

What I would prefer would be to enable debug based on a "module". This
could be a class or a file. eg. With log4cxx I use a static s_log object
in each class, each one with the class name as an identifier. A file
given as a command line parameter controls what is available. Previously
I used a system where logging was by filename. The log macro passed in
__FILE__ and another file at runtime just had a list of files that were
matched.

Another one that works ok is to have aspect based selection. There's a
defined number of aspects and each log call specifies what it is, then
these can be controlled with command line parameters. MythTV uses this
and has aspects such as video, audio, playback, timing, etc. This way
logging is easily enabled for a whole aspect no matter what files it is
in, and only the relevant logging for each file is enabled, not all of
it.

I suspect the latter approach is probably less applicable to box but I
don't mind any of them really. The only important thing is to make it
light weight, I don't think any of us want to be responsible for
maintaining a heavyweight logging system nor reinventing the wheel.

> You could also implement an extra command in bbackupctl to change the  
> logging level in a running bbackupd process, which would be handy  
> when it's doing something you want to know more about.

That could be handy. What about server side? A signal maybe?

Cheers,

Martin.




More information about the Boxbackup-dev mailing list