[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #38 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-19 03:45:14 PDT ---
Transcript of some discussion on IRC:

14-07-2010 14:39:59 < sjoerd: smcv: why does the REquestSubscription spec entry
talk about aliases
14-07-2010 14:40:44 > smcv: sjoerd: because they used to be on that interface,
and because in any protocol with user-set aliases, you should probably set one
14-07-2010 14:41:18 > smcv: sjoerd: (see <tp:rationale>)
14-07-2010 14:41:36 < sjoerd: that's great and all, but i don't think it
belongs there and it's just confusing
14-07-2010 14:42:25 > smcv: the other reason is that something (either
Aliasing/Names or RequestSubscription) ought to recommend an order in which to
set them
14-07-2010 14:43:16 < sjoerd: That's should probably be in the description then
14-07-2010 14:43:31 < sjoerd: It's more of a guideline then documentation of a
specific method
14-07-2010 14:43:41 > smcv: and indeed to try to avoid the failure mode that
Empathy has / previously had, where it sets the user's alias to their
identifier, then their nickname turns up, but you'll never see it because the
local alias takes precedence
14-07-2010 14:44:19 > smcv: (Gabble does that too, as a protocol workaround,
but IMO it's worse that Empathy does, because that also hurts Haze,
particularly for protocols like ICQ where the identifier is opaque)
14-07-2010 14:44:33 < sjoerd: That's not the specs problem
14-07-2010 14:45:39 > smcv: I agree the description is too short, it should
summarize what you do
14-07-2010 14:50:39 < sjoerd: smcv: hmm, does (SubscriptionPersist = True,
CanChangeSubscriptions = False) ever occur?
14-07-2010 14:50:49 > smcv: sjoerd: facebook
14-07-2010 14:51:13 < sjoerd: smcv: not on a protocol level though, gabble
won't know that
14-07-2010 14:51:28 > smcv: sjoerd: it'd be better UI if it did
14-07-2010 14:51:48 > smcv: sjoerd: likewise editing out some
interfaces/actions/flags if it notices it's on facebook chat
14-07-2010 14:51:50 < sjoerd: but i guess you could imagine a faceobok like
situation with a none-xmpp chat protocol
14-07-2010 14:51:54 > smcv: yeah
14-07-2010 14:52:15 < wjt: is this something profiles should cover?
14-07-2010 14:52:21 > smcv: if I get round to writing telepathy-1970 it'd be
like that
14-07-2010 14:52:29 > smcv: (the contact list would be /etc/passwd :-P )
14-07-2010 14:52:35 < sjoerd: heh
14-07-2010 14:52:39 < sjoerd: wjt: probably
14-07-2010 14:53:00 < sjoerd: smcv: can we call them ContactListPersis and
CanChangeContactList btw ?
14-07-2010 14:53:30 < * sjoerd finds things like: CanChangeSubscriptions:
presence subscription and publication can be changed confusing
14-07-2010 14:53:58 > smcv: wjt: the advantage of getting it from the CM is
that if we can talk the facebook people into adding some stream
anticapabilities, and their server becomes more capable in future, we don't
have capabilities arbitrarily swithced off by an out of date profile
14-07-2010 14:54:13 < sjoerd: well
14-07-2010 14:54:21 < sjoerd: profiles are essentially an overlay aren't they
14-07-2010 14:54:29 > smcv: yeah
14-07-2010 14:54:44 > smcv: "I happen to know that this feature doesn't work",
in this case
14-07-2010 14:54:49 < sjoerd: So we should have them in the CM as well, but in
the facebook case the profile can indicate extra restrictions on top of the
protocol, which would be current
14-07-2010 14:54:57 < sjoerd: *correct
14-07-2010 14:55:39 < wjt: so in this case it would be "override this
connection property to have this hard-coded value"
14-07-2010 14:55:43 > smcv: by "have them in the CM" do you mean ship a
.profile with gabble, or what?
14-07-2010 14:56:27 > smcv: sjoerd: vague rationale for it being Subscriptions:
subscription and publication are different ways to look at the same thing
really
14-07-2010 14:56:42 > smcv: but yeah those could change to be ContactListFoo
14-07-2010 14:57:40 < sjoerd: Yeah, i know it's all different views, which is
what it makes it confusing :)
14-07-2010 14:57:56 > smcv: also, CanChangeSubscriptions is really what we mean
14-07-2010 14:58:13 > smcv: well, I suppose "can change subscriptions, and
publication negatively"
14-07-2010 14:58:16 > smcv: or some such
14-07-2010 14:58:29 > smcv: aagh
14-07-2010 14:58:51 > smcv: I don't want to get into the group flags situation
again, let's call it CanChangeContactList :-)
14-07-2010 14:58:59 < sjoerd: hehe
14-07-2010 14:59:38 > smcv: I think it's reasonable to say that if you can
request subscriptions, but you can't (say) revoke publication, then your CM or
your server or both suck
14-07-2010 15:01:02 < sjoerd: the REquestContactList thing mikhailz raises is
interesting
14-07-2010 15:01:50 < sjoerd: makes me wonder if we should have a
ContactListRetrieved with a change signal
14-07-2010 15:02:17 < sjoerd: time to make more tea and ponder on the failure
cases :p
14-07-2010 15:02:48 > smcv: I think the quad-state that mikhailz suggests might
be a good model
14-07-2010 15:03:10 > smcv: if you want to know where we've got to, just look
at it
14-07-2010 15:03:22 > smcv: if you want to wait for it to resolve, call the
method
14-07-2010 15:03:32 > smcv: if you want to know why it failed, call the method
14-07-2010 15:04:02 > smcv: and you can either try the method again on timeout,
or set a long timeout, or whatever you like
14-07-2010 15:12:25 < sjoerd: everyone will get that error path wrong though
14-07-2010 15:16:06 > smcv: we also can't usefully make contact list edits
without waiting for the initial contact list, so...
14-07-2010 15:17:07 > smcv: I should probably write client API on TpConnection
to make sure it's possible to do so
14-07-2010 15:20:28 < sjoerd: yeah, i think i'd argue for option 1 in comment
35, but you and wjt apparently think that makes things harder
14-07-2010 15:26:13 < wjt: sjoerd: yeah, i guess i stand by that position| ~@~T
it adds one more async step in any client using thiss
 interface
14-07-2010 15:27:52 < sjoerd: wjt: then again every client will get it wrong
when retrieiving the contact lists takes a long time
14-07-2010 15:28:20 < sjoerd: and it means for editting every CM probably needs
a queue
14-07-2010 15:30:33 < sjoerd: wjt: the extra async step you need, is the same
you also need to handle the slow contact list retrieval error case though. it
just moves it forward
14-07-2010 15:31:12 < wjt: mmm
14-07-2010 15:31:46 > smcv: I wonder whether writing (or at least documenting)
the client API would be illustrative
14-07-2010 15:32:35 < sjoerd: the tp-glib API should just be turning on the
feature which causes it to retrieve the contact list
14-07-2010 15:33:05 < sjoerd: it should hide all the silly timeout stuff for
clients
14-07-2010 15:33:10 > smcv: right
14-07-2010 15:33:19 > smcv: but when should contact list manipulations work?
14-07-2010 15:33:28 > smcv: a) after the feature has been prepared
14-07-2010 15:33:35 > smcv: b) after you connected
14-07-2010 15:33:47 > smcv: c) your alternative here
14-07-2010 15:34:26 > smcv: bearing in mind that a contact list manipulation
(RequestSubscription, say) is async anyway - it'd make most sense to have it
encapsulate any other async round-tripping that needs to happen first, I think?
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 :-/
14-07-2010 15:37:51 > smcv: hmm, actually
14-07-2010 15:37:57 < sjoerd: so network roundtrip, so timeout hell again
14-07-2010 15:38:13 > smcv: yes, but methods being a network round-trip is
nothing new
14-07-2010 15:38:35 > smcv: the only reason this interface is unusual is that
some servers have been observed to take longer than is sane to fetch the
contact list
14-07-2010 15:38:38 > smcv: (apparently)
14-07-2010 15:39:22 < sjoerd: Maybe you're 3G is better then mine, but it's not
uncommon to be on a train and a login taking forever
14-07-2010 15:39:31 > smcv: any "write", like setting your nickname or
whatever, ought to wait for the network round-trip before returning, otherwise
we can't indicate errors
14-07-2010 15:40:02 > smcv: but yes the difference is that the contact list is
bigger, so it's a lot more likely that the initial contact list pull will take
longer
14-07-2010 15:40:41 > smcv: and because we can't edit the contact list until we
know its initial state, that potentially carries over into the other methods
14-07-2010 15:40:47 < sjoerd: yes
14-07-2010 15:43:13 > smcv: OOI, do you get a contact list successfully with
current Telepathy? the long-round-trip is isomorphic to what you have to do at
the moment, which is EnsureChannel() for a contact list channel
14-07-2010 15:44:59 < sjoerd: we set the timeout to MAXINT
14-07-2010 15:45:04 < sjoerd: well empathy does that
14-07-2010 15:45:08 < sjoerd: no simple client ever does that
14-07-2010 15:45:19 > smcv: right
14-07-2010 15:45:31 > smcv: (and I discovered while investigating that Qt can't
:'-( )

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