[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #41 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-21 03:29:58 PDT ---
(In reply to comment #40)
> > 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*.

This turns out to be harder to implement than you'd think, because
tp_base_contact_list_contacts_changed enforces the condition that state be
recoverable (the subclass must update its internal model, then pass a list of
contacts to tp_base_contact_list_contacts_changed, and that method asks the
subclass for the changed contacts' states.

I could change that API, but I think the need to change it is a symptom of
breaking state-recoverability of things that ought to be state-recoverable,
which we don't really want anyway.

One possibility is to replace Rejected with Remote_Removed or something, with
the following semantics:

* For subscribe, it's the same as the current Rejected: subscribe changes from
Ask to Remote_Removed when the remote user denies our request, and you can
"acknowledge" by calling Unsubscribe() or RemoveContacts(), at which point
subscribe changes to No (and the contact is removed if appropriate). If
subscribe changes from Ask to No, that means either we cancelled it, or we
don't know why it changed.

* For publish, if publish=Ask, Unpublish() or RemoveContacts() rejects a
publish request (publish changes from Ask to No). If publish changes from Ask
to No, that means either we (or another of our resources) cancelled it, or we
don't know why it changed. If publish changes from Ask to Remote_Removed, that
means the remote contact cancelled their request: you can "acknowledge" by
calling Unpublish() or RemoveContacts(), at whick point Remote_Removed changes
to No and the contact is (probably) removed.

This is fully state-recoverable, although more subtle.

Another possibility is to have an Actor or Locally_Initiated or something in
ContactsChanged.

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