Remotelogging stuff (Re: Revision 4f37cd..)

[Shkutkov Michael]

Sadrul Habib Chowdhury wrote:
> * Does it make sense to send the account and name to the callbacks
> (PurpleLogListCallback etc.)?
>   

Actually I don't this so, this is an extra data which isn't really 
necessary. Look at gtklog.c
(remotelogging branch) you could see that account and name in 
PurpleLogListCallback aren’t used.
And I think it's really easy to pass them in callback through user data 
if necessary.

> * Instead of maintaining a counter in the callback data, does it make
> sense to use something like a PurpleLogContext or something)? For example,
>
>   PurpleLogContext *ct = purple_log_context_new(destroy_context_cb);
>   purple_log_context_set_userdata(ct, some_data);
>   purple_log_read_nonblocking(ct, ..., callback_fn, ...);
>
> and the _nonblocking functions will _ref the 'ct', and an internal
> log-callback (not 'callback_fn') will _unref it, and call
> 'destroy_context_cb' when appropriate.
>
> Am I making any sense, or making things unnecessarily more complex than
> they need to be?
>
>
>   

First of all we need counter if we have several nonblocking log calls 
like in gntblist.c (because we
need to know when all calls will finish, to make some things and free 
user data)
If we have only one nonblocking log call we don't need counter and 
context too
(So it seems that rather often PurpleLogContext is unnecessary)

I guess you would like to simplify all staff related to counter.
I've thought about this, but question is when it will be appropriate to 
call destroy_context_cb?
We can't do this if ref count is zero, because not all loggers implement 
their methods in nonblocking style
(and this is all right, we need only those that have big delays). So 
it's really often when ref is zero,
but we haven’t finished so we shouldn't call destroy_context_cb. (Maybe 
it's hard to understand)

Another problem, is how free user data (which stored in context). We 
should do this after last
nonblocking call, but how to determine it?

> PS: Oh, and we can do 'gpointer data', instead of 'gpointer *data'
>   
Could you provide a piece of code for clarity. Where we should make this 
replacements?

-- 
With best regards,
Shkutkov Michael