Re: Balsa's terminal logging

Albrecht Dreß <[email protected]> Fri, 12 Jan 2018 18:55:16 +0100
Newsgroups	gmane.comp.gnome.apps.balsa
Message-ID	<[email protected]>
Hi Peter:

Am 12.01.18 00:40 schrieb(en) Peter Bloomfield:
> If we define the G_LOG_DOMAIN macro as "libnetclient" in libnetclient/Makefile.am, like the Gtk+ docs suggest <URL:https://developer.gnome.org/glib/stable/glib-Message-Logging.html#G-LOG-DOMAIN:CAPS>, we could continue to use the g_debug() etc. macros.

Ah!  I wasn't aware of that feature, shame on me!  This is of course *a lot* better!

>>>> 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.
> 
> I'm not sure about using g_info(). It *sounds* the same as g_message(), but it's *handled* the same as g_debug() (wrt G_MESSAGES_DEBUG), and it just confuses me!

Well, not completely…

In my proposal above, g_message() (and warning/error/…) will *always* be printed to stderr.

g_info() would be controlled by the preferences setting for balsa_app.debug (Miscellaneous 🠆 Debug) /and/ by G_MESSAGES_DEBUG.  I.e. the user could switch these messages on and off during runtime if G_MESSAGES_DEBUG is undefined.  It is questionable whether this is actually useful, though.

g_debug() would solely be controlled through G_MESSAGES_DEBUG.

But I fully agree with you that this looks somewhat over-complex!

As alternative, we could drop g_info() and always use g_debug(), controlled by either balsa_app.debug (which would imply G_MESSAGES_DEBUG=all) or by G_MESSAGES_DEBUG, respecting the domains in the latter case.  The advantage would be the ability to switch these messages on and off during runtime.  But the drawback is that the debug messages for libnetclient dump the complete, unencrypted network IO, including authentication data.  I'm afraid that some users may blindly activate this setting (in the German translation the option is even called “Fehlerdiagnose” = “error diagnosis”, “troubleshooting”!), regularly leaking their account information to a log file.  Omitting this data from the /very/ low-level debugging would be feasible, but sometimes it is required to track down issues…  So, I don't think this would be a good solution.

Or, we could drop the “Miscellaneous 🠆 Debug” item, use only g_debug() and control it through G_MESSAGES_DEBUG.  This might actually be the best the best approach.

>> 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, …?
> 
> The Makefile.am method I mentioned above works only at the SUBDIR level, of course, not as fine-grained as this. But G_LOG_DOMAIN could be redefined in any source file (or header file) that wanted to override the SUBDIR domain. It still seems like less of a hassle than defining a complete set of DOMAIN_DEBUG etc macros for each DOMAIN.

Yes!  This is of course much better.

I still think the fine-grained control might be helpful (think of a problem with, say, a LDAP address book – you don't want to see /everything/ from libbalsa!).

So, please forget my first patch…  I feel this topic needs more discussions before diving into /real/ coding!  IOW, comments are welcome… ;-)

Cheers,
Albrecht.

_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
signature.asc (application/pgp-signature, 473 B)