Michael Sinz raised a good point which received no replies:
> I may be a bit "old school" here but why is there so much work and
> effort going into re-inventing "syslog" logging.
> Windows does have application event logging support [...]
Server applications which run on Unix are historically somewhat split
on whether they implement home-grown logging subsystems or use syslog.
sshd syslogs, for instance, while httpd uses a home-grown subsystem.
I tend to think that the former are being more responsible citizens,
at least as Unix programs go. They tie into the system's central
logging configuration and central log-rolling mechanisms.
It's true that going with the native logging system on each platform
would be a more difficult path. We'd have to add functionality to APR
(which has never concerned itself with this problem because httpd uses
a home-grown logging subsystem), and we'd have to figure out what the
best native logging facility is on various platforms, as well as
figuring out how to provide a uniform interface to those platforms'
logging levels and facilities. But in the long term, a home-grown
logging subsystem is extra complexity which we could never practically
rid ourselves of.
We could, of course, add configurable hooks to our home-grown logging
subsystem (now or later) to log via the platform's native logging
system. But we'd still have a bunch of gunk in the Subversion source
base which reinvents the wheel.
I'm not adamant about using the platform-native logging facilities,
but before we get too far down the home-grown subsystem path, I'd like
to hear arguments for that path over the platform-native one.
One possible criticism is that using syslog on Unix unconditionally
would not make it easy to interoperate with Dan Bernstein's
daemontools as John Szakmeister (I think; both mail archives are down
right now) desired. It's my opinion that it is not important or even
desirable to put any weight on interoperating with djb's tools, since
they are themselves designed without any weight for consistency with
other Unix facilities.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 20 23:06:30 2005