[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #40 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-20 04:34:51 PDT ---
An additional concern: we currently assume that the CM will fetch the contact
list. There is a somewhat questionable use-case for not getting the contact
list. Quoting RFC 3921:

"""Upon connecting to the server and becoming an active resource, a client
SHOULD request the roster before sending initial presence (however, because
receiving the roster may not be desirable for all resources, e.g., a connection
with limited bandwidth, the client's request for the roster is OPTIONAL). If an
available resource does not request the roster during a session, the server
MUST NOT send it presence subscriptions and associated roster updates."""

Sjoerd thinks we don't need to care about this, and can just get the contact
list unconditionally, because in practice nearly every client will want it. To
consume less bandwidth, we should implement XEP-0237 Roster Versioning (Bug
#26489 - getting the roster as a diff since the last known version) rather than
trying to avoid getting the roster (which in practice won't happen).

However, if we do (or might) want it to be conditional, it should be opt-in
now, because turning opt-in into guaranteed is compatible, but turning
guaranteed into opt-out is not. The opt-in could be via client interests (Bug
#27835) or something else. So, if anyone disagrees with Sjoerd, speak now!

(In reply to comment #39)
> 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.

Sjoerd seems to approve.

If we keep the contact list download as a guarantee, None and Waiting are
synonyms, so we can just use Waiting|Success|Failure.

> 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

Sjoerd suggests allowing this method automatically prepare
TP_CONNECTION_FEATURE_CONTACT_LIST, but require that
TP_CONNECTION_FEATURE_CONNECTED is already prepared. I think that sounds
reasonable.

> 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.

After discussion with Sjoerd, I suggest we loosen ContactsChanged to say that
the same contact can be in both Changed and Removed, Changed applies first,
contacts not on the contact list can have either publish=No or
publish=Rejected, and putting them in Removed implies a change to No *unless
it's already No or Rejected*. Then we can have:

* Alice requests presence from me
  ContactsChanged: Changed={Alice: (sub=No, pub=Ask)}
* if I reject the request with RemoveContacts() or Unpublish():
  ContactsChanged: Changed={Alice: (sub=No, pub=Rejected)}, Removed=[Alice]
* or if Alice cancels it:
  ContactsChanged: Changed={}, Removed=[Alice]
  or if we want to be more explicit, this is equivalent:
  ContactsChanged: Changed={Alice: (sub=No, pub=No)}, Removed=[Alice]

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