Branko Čibej <firstname.lastname@example.org> writes:
> >Developers and users
> >alike could get a lot of help from tracing and verbose logging. It's
> >been requested several times on the mailing list. I'm sure if the
> >functions were there today many people would start using them.
> Please do not confuse "verbose logging" and "debug tracing". Logging
> and debug tracing are conceptually different and imho should not be
> implemented in the same way.
> Logging provides a record of the operations performed by the
> applicatio (e.g., requests served), as an input for audits and
> security analysis. It's turned on by default, typically cannot be
> turned off completely, allows only minimal choice of verbosity and
> output configuration (e.g., songle log file vs. separate noremal/error
> log, etc.), and does not significantly affect application performance
> even in the most verbose configuration.
> Debug tracing is a tool intended to help developers to diagnose
> problems. It's turned off by default, provides lots of different knobs
> for controlling the amount, verbosity and source of the trace data,
> and is allowed to slow application performance to a crawl if a really
> detailed trace is required. Typically that means that tracing is even
> implemented differently than logging.
> I've seen logging and debug tracing being discussed in the same breath
> (and implemented as if they were the same thing) so often that it
> hurts. I don't want this to happen in Subversion.
Brane, while I respect your opinion on this matter, I think that
seeing these two topics discussed together only "hurts" because you've
brought a handbag full of assumptions to the table, none of which
you've bothered to share with anyone. Surely you can see how the
obvious first stab at solving both debug tracing and verbose (or
non-verbose) logging is to implement them both using the same
mechanism, where debug tracing is simply really really really really
verbose logging, with perhaps several log levels between that and the
most verbose output that the average setup would desire (think Apache
LogLevel here ...). There's no reason to assume that one or the other
will necessarily degrade performance, either, but even so it would be
reasonable to expect higher log levels to have higher performance
penalties, and no sane person could dispute that ("What do you *mean*
doing more work takes more time!? How dare you!")
So, while it might be the case that once higher-detail design
discussions are being had about these features we find that its best
that they don't share the same (or even similar) codepaths, let's have
those design discussions first before pistol whipping our eager
And yes, you may even say, "I told you so" when we come 'round to
seeing things your way.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 13 04:22:42 2005