Re: slapd logging changes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I'd like to see this generalized a bit to support other
OpenLDAP applications.  That is, the logging system should
support not only slapd, but slurpd and even the client tools.
It's just that the some applications have less subsystems
than others.  One tricky part of all this is that the
logging needs to be integrated with -lldap/-llber in a
way that does interfere with use in other applications.
In particular, an LDAP application must not be required
to link in -llutil.  However, OpenLDAP applications could
use an -llutil routine which plugged in the right stuff into
-lldap and -llber to get subsystem logging... [which is
quite appropriate if logging supports syslog].

Also, I think "application" (or "main") should be added as a
subsystem to provide control over logging within the main
body of the application.  Also, logging should be configured
via command line directives as one often needs logging before
any configuration file can be read.  This is especially
true for slapd.

I also would like to see mnemonics introduced for levels.
Mnemonics will promote more consistent usage.

Levels should be something similar to what syslog offers,
as these are well understood (and allows for OpenLDAP
logging to use syslog directly).

I believe that statistics should be either handled as
a separate subsystem and not as a level... or, alternative,
separate from the subsystem:level mechanism.

At 02:17 PM 9/29/00 -0400, Gary Williams wrote:
>How the subsystems are broken up warrants further discussion,

Decided what subsystems are needed is the easy part...
I'm happy with one subsytem for the main application,
one per library, one per backend, and one per other
(application defined?) major subsystem

>but this is the basic mechanism.

 From the various posts I've seen on this subject, folks
seem to agree that subsystem:level mechanism is fine.

Are there other design considerations which need to be
taken into account?