Hi Peter: Am 06.01.18 05:26 schrieb(en) Peter Bloomfield:
2018-01-05T14:55:42.161399Z balsa:(main) WARNING[libbalsa]: some message from libbalsa 2018-01-05T14:55:42.161414Z balsa:4008e0 ERROR[default]: error message from thread 0x4008e0 iso8601 time stamp thread level[domain] I'm not sure if the domain is of any use (probably not), so we could just omit it.If that is the domain that is selected in G_MESSAGES_DEBUG, I feel that we should start using it. Running Balsa with "G_MESSAGES_DEBUG=all" sometimes spews messages from many other uninteresting domains!
Hmmm, that's a good point! Attached is a patch which implements our own log handler (partly stolen from the GLib 2.48 implementation), respecting the log domains from the environment: * DEBUG messages are printed to stdout only if G_MESSAGES_DEBUG includes either “all” or the specified domain * INFO messages are printed to stdout only if balsa_app.debug is TRUE, or if G_MESSAGES_DEBUG includes either “all” or the specified domain * all other messages are always printed Of course, this could be modified easily, e.g. by treating the level MESSAGE (which is printed to stderr) like INFO. I added a new domain "libnetclient" for all low-level network IO in libnetclient as an example (see below).
Our log handler should evaluate the balsa_app.debug setting and the G_MESSAGES_DEBUG environment variable: * levels ERROR, CRITICAL, WARNING, MESSAGE: always print to stderr * level INFO: print to stdout only if balsa_app.debug is TRUE, and maybe G_MESSAGES_DEBUG is defined * level DEBUG: print to stdout only if G_MESSAGES_DEBUG is defined The calls to [f]printf, g_print and g_printerr need to be converted to the appropriate macros: * fprintf 🠆 g_info() for balsa_app.debug, g_warning() or g_error() otherwise * printf and g_print 🠆 g_info() for balsa_app.debug, g_message() otherwise * g_printerr 🠆 g_warning() or g_error()It looks like a very useful discipline to me.
Well, now the /real/ work begins - how should domains be assigned, and which log levels should messages have? Regarding the domains, I could imagine: - libnetclient: low-level network IO, typically including sensitive user name/password data, so it should be a separate domain - crypto: everything related to message encryption (GnuPG/GpgSM, not to TLS) - compose: everything related to composing messages - send: everything related to sending messages (excluding libnetclient and crypto stuff) - receive: everything related to receiving messages (excluding libnetclient and crypto stuff) - more? E.g. addressbook, filter, preferences, …? Regarding the levels, I tend to shift most of the g_message/g_print/[f]printf messages into INFO and DEBUG, as they typically are not really useful. The drawback is that we would have only two log levels left. So we might want to treat MESSAGE like INFO (see above) to get a third level. What do you think? Cheers, Albrecht.
Attachment:
balsa-logging.diff.bz2
Description: application/bzip
Attachment:
pgpLazGJa5rU2.pgp
Description: PGP signature