[Bug 21787] Connection.Interface.ContactLists

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jun 28 16:54:47 CEST 2010


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

--- Comment #35 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-06-28 07:54:47 PDT ---
Another timeout-related issue is what happens if you want to alter the contact
list (RequestSubscription, SetGroupMembers, etc.), which I expect will require
that you've already retrieved the contact list in most protocols.

Options:

1) Until the contact list has been retrieved, all alterations fail.

This is essentially equivalent to ContactList channels, which you must request
(with CreateChannel or EnsureChannel, and the potential for a timeout!) before
you can call their methods.

wjt and I think this model is harder than it needs to be; in practice it means
that every non-buggy client that wants to manipulate the contact list will need
to invent a queue of "things I want to do when the contact list is ready".

2) The contact list is guaranteed to be retrieved before CONNECTED. Alterations
fail with Disconnected until the status changes to CONNECTED. After CONNECTED,
alterations immediately succeed.

This avoids the timeout issue completely (connecting is already more than a
single method call), but it means that CONNECTED is delayed even further, which
I don't think is desirable; a lot of things only work after CONNECTED, and on
some protocols you have to do quite a lot of work to get the contact list (as I
understand it, on MSN it's kept on a different server).

3) Until the contact list has been retrieved, alterations are queued. When the
contact list has been retrieved, we start acting on alterations.

wjt and I think this is the way forward, and it's what I've implemented in
Gabble. It does have the disadvantage that if you make an alteration before the
contact list has come in, you should set a larger-than-default timeout for it.

If it takes longer than the timeout, the UI will indicate a failure, but the
side-effect will eventually happen anyway - indistinguishable from the same
change being made by a different XMPP resource or something - so I don't think
that's necessarily such a big problem. If you don't want to have non-default
timeouts on calls other than RequestContactList, you can also queue calls in
the client, as with (1).

4) Alterations are possible right from the start (even before CONNECTED). When
the contact list has been retrieved, we start acting on alterations.

In practice, this is the same as (3), because most alterations require you to
have some contact handles, and those don't work until you're CONNECTED. I don't
think it's useful to be able to delete and empty groups in advance, and those
are the only alterations I can think of that don't need a contact handle :-)

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



More information about the telepathy-bugs mailing list