Re: Logging: home-grown mechanism or syslog/event-log?
From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-07-21 05:27:15 CEST
On Jul 20, 2005, at 7:53 PM, Brian Holmes wrote:
It's funny. On Monday, kfogel, cmpilato and I came up with a
However, interestingly enough, we've taken previous hints and gone
Here was our idea:
---- I. Implement a 'logger' class. In libsvn_subr, this is just a filtered stream, nothing more. A "logger" object just contains an svn_stream_t to write to, and loglevel to control the writing. We create a bunch of convenience constructor APIs, and a single API like svn_log_write (logger, loglevel, fmt, ...) If the loglevel being passed in is <= the logger's internal loglevel, we apr_psprintf() the varargs and write the message to the stream. Otherwise we do nothing. This makes the abstract concept of "logging" available to any library or program. II. Encourage use of global logs In /etc/subversion/, create a conf file that contains "pointers" to an accesslog and errorlog for all svn-related processes to share. Admins are free to make the pointers go to private svn logfiles, or into syslog, or into a location that some existing log-rolling daemon will notice and automatically manage. It's flexible. A server process (or any process that wants to log things) has an API to read the 'global' pointers and get back a couple of logger objects. This would be considered a "well behaved" process. A process is also free to ignore this global pointers, and create logger objects to write stuff whereever it wishes. (For example, svnserve could still decide to implement per-repository logging if it wished, by creating its own logger objects whenever it opens an svn_repos_t.) ---- This doesn't seem like very much code to me. I agree that maybe this could be sublimated into APR, but it also seems pretty general and simple. To me, the "big coding task" that's going to create tons of churn (and require maintenance) is teaching our servers to *call* the logging API in a million places. The actual logging infrastructure described above, even if homegrown, seems pretty tiny to me. --------------------------------------------------------------------- To unsubscribe, e-mail: email@example.com For additional commands, e-mail: firstname.lastname@example.orgReceived on Thu Jul 21 05:27:59 2005
This is an archived mail posted to the Subversion Dev mailing list.