Pierangelo Masarati wrote:
There is no "plan" - OpenLDAP grows when an interested developer shows up and writes code that they're interested in. There was an effort to introduce various log levels back in the OpenLDAP 2.1 timeframe but it turned out to be too cumbersome and we eventually gave up on it. If someone else wants to take a stab at it, they're welcome to give it a go.
During the lifecycle of OpenLDAP 2.3, we were requested by a customer to provide syslog level capability in custom code. The request sounded fair enough to result in a general feature that eventually made it into 2.4 (the "Log" macro family).
Ah right, forgot about that.
However, at that time,
- resources (read: money and time) were too short for the thousands of
messages in OpenLDAP sources
- a change of the whole code would have required consensus in general, and
consensus on the most appropriate level for each message, or at least for each message type, and we couldn't guarantee this within the time constraints of that work.
So this feature was wrapped by the old "Debug" macro to preserve the original behavior. If anybody feels like classifying the messages, seeking consensus on syslog levels, and modifying the code accordingly, I think this effort would be more than welcome. As a side effect, it would allow to get rid of the format mismatches when compiling with -Wall :)
Yes, would be nice, but it's more than just reclassifying existing usage. LDAP_DEBUG_TRACE is far overused since it is effectively a level and not a proper subsystem. Eliminating it would require the introduction of many new subsystems. (Of course some of the experience from the earlier attempt may still apply here.) Likewise LDAP_DEBUG_ANY is used for all errors; the point is that these messages are important no matter what subsystems you originally requested. LDAP_DEBUG_NONE should probably have been named LDAP_DEBUG_ERROR instead since that's what it's really used for on the commandline.
Our commandline and config syntax would need to change to specify logging pairs instead of simple keywords or bitmasks; e.g. "-d config.warning" (much like syslog itself).
One thing I think we've learned by now, migrating this is bigger than a summer student project.