Re: libsvn_repos logging -- rethunk

Ben Collins-Sussman wrote:
> So we're backtracking a bit, and proposing this more grandiose vision:
>
> I. Repositories have an accesslog and an errorlog.
>

I'm depressed that I am, to date, unable to articulate to anyone else why I
think this design is too limited in scope. My primary objection remains that it
assumes that everyone will want to write log _files_ and there is no way to
expand it beyond that realm. I fully and freely admit that *most* people will
want to log to files, but this design will not permit any other scheme to be
added later without completely replacing the interface (i.e. 2.0).

I'm also not clear why I am unable to describe my reasoning behind the use of a
structured log object. It seems so much easier to do this:

     svn_log_baton_t log = svn_init_log(repos);
...
     if (level < log.level)
         svn_log_error(log, level, "message");

where the "log" object contains all of the information required to output the
log. The proposed API requires the caller to keep track of a bunch of values
which don't change over the lifetime of the operation, or to retrieve them with
a function call anytime they are used. No matter how clever a macro is, a
straight access to a struct element is faster and (IMNSHO) better that a global.

There are a number of other advantages to a scheme like I am proposing:

1) each library would be capable of having a dedicated log file, or not, with a
different "global" log level or not;

2) for testing purposes, it would be easy to temporarily set the log.level to a
higher number in a specific section of the code, to facilitate targeted logging;

3) because the actual logging happens only in the library, it is much easier to
extend it to include logging to other resources (syslog, database, ???) without
affecting the callers at all.

However, I'm completely swamped now; I'm going to Israel for most of August and
I'm trying to get all of my ducks in a row. I don't have time to work up a more
fully formed proposal, which I regret (since this is one of the topics I am very
interested in improving). As long as the eventual API includes a way to send
all logging to STDOUT (even if I have to use /dev/stdout), I will be basically
satisfied, since I can use multilog to manage my svnserve log files. But I
wanted to make one last effort to register my objections.

Thanks for listening...

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org