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

[Chris Wilson]

Hi Martin,

> I'm not sure why both TRACE and DEBUG are needed, nor why you'd use one
> over the other. Have you plans for using these for specific things?

No, I didn't have any specific plans, I'll drop the DEBUG level.

> Ok. I take it Filter() sets the minimum level that will be logged? Since
> this is on each Logger class I presume it will be possible to set the
> level differently for each output method?

Yes, that was my intention. If you run box with "increased verbosity"
from the command line, you probably want more detail on the console, but
not necessarily in the Windows event log. Similarly for a command-line
"quiet" option. On the other hand, a single global level would be easier
to implement.

> I take it that the Log class will also have a static Log method that
> calls the Log methods on the underlying Logger objects?

Actually, I was thinking that the global function would access the
vector of loggers directly to dispatch the log messages, and a static
method wouldn't be necessary, but it would be a cleaner alternative
design (I've only just learned about static methods in C++). I don't
expect anyone to call it directly, but through the BOX_* macros.

> > A hidden static boolean to disable all logging temporarily, and a class
> > which you can create on the stack to disable logging and have it
> > re-enabled automatically when the class is destroyed.
> 
> Is this needed for a specific purpose?

I have a general idea in mind, but no specific cases where I'd use it
(yet), so I'll leave it out. I was thinking that some messages get
double-logged on Win32 because function A (which knows the filename)
calls function B (which knows the error code) and you need both pieces
of information for debugging. Perhaps it would be better to add
temporarily a special filtering logger to the vector, that captures the
log messages and prevents them being dispatched to the other loggers?

> Another question - I notice you branched for this off trunk again. But
> you've also got another branch for the visual c stuff. What state is
> that in - is it ready to be merged yet? Thinking you're just going to
> end up creating yourself conflicts given the intrusiveness of the
> logger change.

I'd like to merge everything except the type changes, which need to be
reviewed. I'm happy to sort out any conflicts, but I might delete the
logging branch I took the other day and take a fresh one if trunk ends
up changing significantly.

Thanks for your comments!

Cheers, Chris.
-- 
  ___ __     _
 / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |