Revision 755d5487f554cf585f3b988088dc20fad65d1bf6

[Richard Laager]

On Wed, 2007-07-11 at 13:27 -0500, Mark Doliner wrote:
> I kinda feel like, if the logger isn't able to log something, then it is the
> responsibility of the logger to show an error message.

I'm going to disagree with it being the logger's responsibility. Maybe
the core. See below.

> And the caller of
> purple_log_write() shouldn't have to deal with it.  Mostly I'm just wary about
> adding an extra callback function everywhere to free the message.  What do
> other people think?

I think the callback should be optional. If NULL, no callback would be
made. Then existing callers could call purple_log_write_nonblocking with
NULL for each of the callback and data.

This leaves two questions:

1) Should purple_log_write_nonblocking g_strdup from and message, or
should they be char *s that it takes ownership of? Michael, I think you
should see what happens with those variables for most calls to
purple_log_write(). If everyone is immediately freeing those, then we
should have it take ownership instead. If some callers are not
immediately freeing them, then we should have it g_strdup them.

You may find that from is typically being re-used while message is not.
If that's the case, we can leave from as a const char * and g_strdup it,
but take ownership of message.

2) What should the callback's signature look like? If the point of the
callback is to allow the UI to display an error message, what happens if
the UI passes NULL for the callback? Should the logger display an error
message? Should the core? Should the callback return a value telling the
core if it dealt with the error displaying?

The only reason to have the logger display the message would be that it
can provide more details on what happened. If we want that, I think we
should use the GError system that glib provides so the logger can pass
information to the core.

While a bit complex, I'm leaning towards the following solution: The
logger can pass a GError up to indicate a problem occurred. The core
always logs the error. The core passes this GError to the UI in the
callback. The callback returns a boolean value to indicate if the UI has
dealt with the error. If it has not, the core displays an error message
using the notify API and includes the message from the GError.

We could use this same approach for other log functions as well.

This solution would work well in the following cases:
a) A system log fails to write. We let the core pop-up an error
notification.

b) A conversation message fails to write. We print an error message to
the conversation window.

However, if those are the only cases that will ever happen, we could
just deal with that in the core. If it's not a system message and
there's a conversation, we print a message there, otherwise we pop up an
error. We'd still want a GError between the logger and core, though.

Thoughts?

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20070711/de58bf7e/attachment.sig>