On Mon Nov 22 13:31 1999 -0500, Chris Calabrese wrote:
> Alex Brown wrote:
> > I take this to mean that any replacement should observe the syslog(3)
> > API at each UNIX client. Semantics of the parameter lists can be
> > extended (e.g. more facilities can be added) but there should be general
> > backwards compatibility to allow existing client applications to use the
> > replacement with only relinking. It does not seem necessary to retain
> > the syslogd.conf(4) specification.
[...]
> I think everyone agrees that we need to support the existing
> syslog() API for backward compatibility. The question is whether we
> might also have an extended API to get extra capabilities, etc.
Since we're discussing some fairly fundamental changes to the
underlying protocol, I suspect that the current API will wind up being
very cumbersome from a programming standpoint, because it was never
designed with the new protocol in mind. Therefore, I suggest that we
take the time to design a new API which is tailored specificly to our
new protocol. We can handle backwards compatibility with the old API
via dummy openlog() and syslog() calls which call the new API
functions with a reasonable set of defaults. Depending on how the new
API winds up looking, these dummy functions might even be implemented
as preprocessor macros.
--
Mark D. Roth <[EMAIL PROTECTED]>
http://www.feep.net/~roth/
