[Bug 27676] ContactInfo high-level API

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27676

--- Comment #20 from Xavier Claessens <xclaesse at gmail.com> 2010-06-02 08:26:16 PDT ---
(In reply to comment #19)
> (In reply to comment #12)
> > you do need RequestContactInfo with a long (1 hour?)
> > timeout.
> 
> but:
> 
> +  tp_cli_connection_interface_contact_info_call_request_contact_info (
> +      self->priv->connection, -1, self->priv->handle, contact_info_request_cb,
> 
> -1 means the default timeout, usually 25 seconds. Please either take a timeout
> as an explicit parameter (re-interpreting -1 as an hour or something), or just
> set a long hard-coded timeout.

Already did that, I amended the commit. You probably pulled too early :)

> > If the dialog is closed, you can cancel the TpProxyPendingCall to free
> > up some memory
> 
> Using the TpContact as the weak_object as you've done is not actually useful,
> because GSimpleAsyncResult refs the source object (to ensure that the callback
> runs precisely once). This means the only way to cancel the call is with the
> TpProxyPendingCall.
> 
> The intended cancellation semantics of GAsyncResult and TpProxyPendingCall are
> not the same, unfortunately; a GAsyncResult async call always runs its callback
> exactly once, but a TpProxy call does not run its callback if cancelled. I
> think you'll need to make a context struct that contains both the
> GSimpleAsyncResult and the TpProxyPendingCall (or NULL if it already
> completed), and use that as the user_data for the async call and the
> cancellation signal. Alternatively, you could attach the TpProxyPendingCall to
> the GSimpleAsyncResult as qdata, perhaps?
> 
> Either way, you need to keep track of whether it's already finished, since it's
> invalid (use-after-free!) to cancel a TpProxyPendingCall that has already been
> cancelled or called its callback.

None of our wrappers for tp_cli_foo_call_bar() are cancellable. IIRC the reason
is the semantic of GCancellable is to stop a running operation (like reading a
file) but a DBus call can't be stopped, we can just ignore the callback... So I
get told (sjoerd IIRC) that our solution is to use TpWeakRef as user_data, and
in the callback we can check if our object (the GtkDialog in empathy case) is
still alive, and if it is NULL we can return directly.

Do you object?

> > So really the only optional is tp_contact_info_field_spec_new() so I kept
> > public for API completness... but can easily be moved to connection-internal.h
> > if you like.
> 
> I'd be inclined to follow the general principle of "if it doesn't have to be
> public, don't make it public" for that one.

ok, removed it.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.