[Bug 28200] TpBaseContactList

[bugzilla-daemon at freedesktop.org]

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

--- Comment #41 from David Laban <david.laban at collabora.co.uk> 2010-08-04 04:49:29 PDT ---
> https://bugs.freedesktop.org/show_bug.cgi?id=28200
> 
> --- Comment #40 from Simon McVittie <simon.mcvittie at collabora.co.uk>
> 2010-08-04 03:02:12 PDT --- (In reply to comment #39)
> 
> > Needing to handle multiple contacts at the same time is a pain in the
> > ass, if you have to do everything async *before* calling the callback,
> > as the API asks you to (requires looping and counting the number of
> > async calls you make). What is the use-case for adding multiple contacts
> > with the same message?
> 
> At the D-Bus level, the "change" methods are:
> 
> * RequestSubscription: being plural is only useful if you're in a protocol
> like SIP/SIMPLE where the contact list is transient. Empathy could store
> the contact list locally (in libfolks?), and drop it into both
> AuthorizePublication and RequestSubscription every time you connect. On
> the other hand, perhaps we want to declare that connection managers for
> SIMPLE should store your contact list in the XDG_DATA_HOME anyway?

Ah, okay. That makes sense now. Thanks.

> Perhaps it'd be worth making the list (but not group) operations singular
> in C, I don't know. If we do, we should probably make them singular on
> D-Bus too?
> 
> I don't think it's really all that onerous to count changes, though -
> Gabble now has gabble_simple_async_counter_new(), which we could provide
> in telepathy-glib if people like it enough.

Oh, it's not a problem. I guess it's just a case of making sure there is a 
use-case for it not being as simple as I thought it could be.

> > Also, doing it GAsyncResult-based means that your function has two
> > pointers that get passed into it.
> 
> Not our bug; this is how GAsyncResult works, and being consistent with
> other GObject libraries (potentially gaining "free" CM bindings later) is
> important.

I understand the thing of getting "free" GAsyncResult based bindings on the 
client side. I don't understand how this would help you write a tp-glib-based 
CM in (for example) python. Are there also plans to help you implement 
GAsyncResult-based interfaces in other languages? I'd assumed there wouldn't 
be (it seems like a less trivial task, with fewer use-cases). 

If there are plans to help with this too, then ++ times a million on using 
GAsyncResult. Otherwise, it seems a little bit more complicated than an api of 
the form
tp_mutable_contact_list_request_subscription_finished (self, token)/
tp_mutable_contact_list_request_subscription_failed (self, token, error)
with no real gain. That's the only point I was trying to make.

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