Responding to Julien's request for a libmapi logging proposal. There are
so many layers involved with OC that a good system for letting people
select which layer they want to listen to will help people for years to
come. And if we don't think about it we'll end up with Samba DEBUG :-)
1. Principles:
- Don't use Samba DEBUG anywhere, for reasons discussed.
- Offload as much log handling as possible to tools built for the job.
- Encourage libmapi applications to use this system for things
related to MAPI, especially OC server.
- Allow for at least some level of future integration with Exchange
logging in OC Server, by allowing messages to be passed to OC
Server as well/instead of to normal libmapi logging. I'm not saying
to implement anything, just not to make future implementation
difficult.
2. Create a compatible DEBUG macro for libmapi, and similar LOG macro.
Make it possible to send LOG and DEBUG to the same stream, so you never
have to repeat LOG strings in DEBUG.
3. Examine every current use of DEBUG and classify as DEBUG or LOG, and
change the code accordingly. DEBUG log information is exclusively for
helping libmapi developers or libmapi user programmers, eg:
internal_func() returned 23 in line nnn of xxx.c or
nspi_set_dflt_settings: Invalid parameter in line nnn of xxx.c
LOG information is entirely administrative, although it may be very
detailed or technical eg:
Host truc.example unavailable or
mapi_func() returned MAPI_E_UNABLE_TO_COMPLETE in line nn of ndr_mapi.c
4. Allow configuration of debug and log systems so they can write to
files, sockets/domain sockets and syslog. Special case: how do you
log the fact that your logging/debug system is unconfigured or
misconfigured?
5. There is one exception, which is in a panic routine. panic routines
should not rely on any other code. libmapi doesn't seem to have a panic
routine. Have I missed it?
6. Documented log/debug levels. What should each loglevel be used for?
Exchange logging is another topic and I don't have any clear idea on how
it relates to libmapi logging: perhaps just a socket/domain socket
connection. OpenChange Server will need to provide this at some point
because that is what Exchange administrators expect. Diagnostics Logging
is a tab in the MCC Exchange management snap-in and you can generate
*lots* of stuff. Microsoft publish Exchange server error numbers.
Should one loglevel be reserved for Microsoft-compatible logging
information that may go to a different destination than other logging
information?
--
Dan Shearer
[EMAIL PROTECTED]
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
