Revision 755d5487f554cf585f3b988088dc20fad65d1bf6

[Shkutkov Michael]

Mark Doliner wrote:
> On Tue, 10 Jul 2007 18:51:40 -0400 (EDT), mshkutkov wrote
>   
>> -----------------------------------------------------------------
>> Revision: 755d5487f554cf585f3b988088dc20fad65d1bf6
>> Ancestor: 1b455e6f5ef8d75f46d5faa291a761ec59269586
>> Author: mshkutkov at soc.pidgin.im
>> Date: 2007-07-10T21:19:49
>> Branch: im.pidgin.soc.2007.remotelogging
>>
>> Modified files:
>>         libpurple/connection.c
>>
>> ChangeLog:
>>
>> purple_connection_set_state was made nonblocking by using
>>     
> purple_log_write_nonblocking.
>
> I haven't been following the remotelogging branch, but this change seems weird
> to me.  So will we need to change all code that calls purple_log_write() to
> now call purple_log_write_nonblocking()?
>
> Couldn't we just change purple_log_write() to always be nonblocking? 
> purple_log_write() could strdup the message, and then free it after it's been
> written to the file.  So you could get rid of the 'cb' parameter and just
> handle it internally in log.c.  That way the callers of purple_log_write()
> wouldn't need to re-implement it every time.
>
> You could even optimize that a little bit so that purple_log_write() accepts a
> true/false parameter that, when false it strdups the message, but when true it
> takes ownership of the passed in message string and frees it when finished.
>
> -Mark
>
>   
Having puprle_log_write function which call callback maybe useful,
because in callback we know the result of writing message, was it 
successful or not.
So we can handle this information and for example the UI could display a 
failure message.

As C doesn't have function overloading, we could have several writting 
log functions:

purple_log_write_with_cb
purple_log_write_no_dup
purple_log_write

If so, we can leave all code that uses old purple_log_write as it is.

P.S. _nonblocking suffix will be removed later.

-- 
With best regards,
Shkutkov Michael