[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|http://git.collabora.co.uk/ |http://git.collabora.co.uk/
                   |?p=user/smcv/telepathy-spec |?p=user/smcv/telepathy-spec
                   |-smcv.git;a=shortlog;h=refs |-smcv.git;a=shortlog;h=refs
                   |/heads/contact-list-rejecti |/heads/no-waiting
                   |on                          |

--- Comment #39 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-19 10:06:49 PDT ---
(In reply to comment #37)
> I was thinking more about an enum ContactListState =
> (Initial|Retrieving|Retrieved|Failed)
> 
> The error could go to the method return, if you want to keep GCLA as a
> potentially slow roundtrip.

I've added something pretty similar in branch smcv/no-waiting. It's a
quad-state, None|Waiting|Success|Failure.

GCLA is now instant-return again; in the Failure state, it raises an error, and
in the None and Waiting states, it raises a new error, o.fd.T.E.NotYet,
analogous to EWOULDBLOCK. Alternatively, we could make it block if people
prefer.

We can solve the "client-side queue" issue that wjt and I complained about by
making tp_connection_contact_list_request_subscription_async() (etc.) operate
as follows:

* async-wait for the contact list to be retrieved or failed, or invalidation
* if invalidated, fail
* call GCLA
* if invalidated, or GCLA failed, fail with the same error
* async-call RequestSubscription
* fail or succeed as appropriate

and also doing the equivalent in telepathy-qt4.

> 14-07-2010 14:53:00 < sjoerd: smcv: can we call them ContactListPersis and
> CanChangeContactList btw ?

Done in the same branch.

----------------------

Still to do:

As currently implemented, Subscription_State_Rejected only applies to our
subscription to others, not our publication to others - if we reject someone's
request, we still represent that as No, to preserve the fact that all contacts
not on the list have publish = subscribe = No. What do people think about this?

Concrete example:

* Alice requests presence from me
  ContactsChanged: Changed contains contact=Alice, sub=No, pub=Ask
* I reject the request with RemoveContacts()
  - ContactsChanged: Removed=[Alice]
  - or: ContactsChanged: Changed contains contact=Alice, sub=No, pub=Rejected;
        a second ContactsChanged signal has Removed=[Alice]
  - or: ContactsChanged: Changed contains contact=Alice, sub=No, pub=Rejected,
                         and Removed=[Alice]

> 14-07-2010 15:37:02 < sjoerd: When can a CM return from RequestSubscription ?
> 14-07-2010 15:37:31 > smcv: preferably, after the server has acked the
> subscription request in some way
> 14-07-2010 15:37:42 > smcv: in practice Gabble can't do that, because a
> subscription request is presence :-/

I still need to relax the MUSTs to SHOULDs so XMPP CMs can be spec-compliant.

> 14-07-2010 14:45:39 > smcv: I agree the description is too short, it should
> summarize what you do

I'd prefer to wait for the API to settle first :-)

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