|Summary:||[next] Rely on contact attributes in all Connection ifaces|
|Product:||Telepathy||Reporter:||Xavier Claessens <xclaesse>|
|Component:||tp-spec||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||RESOLVED FIXED||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
|Bug Depends on:||33410|
Description Xavier Claessens 2012-05-18 03:35:28 UTC
In Connection ifaces we can remove all GetFoo when we already have a "foo" attribute. For example GetAliases is useless now that we have "alias" attribute.
Comment 1 Xavier Claessens 2012-05-18 03:41:25 UTC
In aliasing iface, I see for GetAliases: """ Also if there was no cached alias, a request SHOULD be started of which the result is later signalled by <tp:member-ref>AliasesChanged</tp:member-ref>." """ GetLocation states almost the same, but GetClientTypes and GetContactInfo doesn't. Should we armonize this? In XMPP, requesting the alias means fetching the vcard with avatar, right? Do we really want that? Also, if the getter says so, the contact attribute should do as well, right?
Comment 2 Xavier Claessens 2012-05-18 03:42:56 UTC
The avatar iface is already taken care of in bug #33410
Comment 3 Xavier Claessens 2012-05-18 05:26:24 UTC
GetPresences says: """ The definition of the connection presence types Unknown and Offline means that if a connection manager will return Unknown for contacts not on the subscribe list, it MUST delay the reply to this method call until it has found out which contacts are, in fact, on the subscribe list. """ Should GetContactAttributes be delayed as well when requesting the presence attribute? I think it shouldn't, clients can check the ContactListState property to know when the presence is probably reliable.
Comment 4 Jonny Lamb 2012-05-18 05:34:41 UTC
I think this is a good idea in principle. (In reply to comment #1) > """ > Also if there was no cached alias, a request > SHOULD be started of which the result is later signalled by > <tp:member-ref>AliasesChanged</tp:member-ref>." > """ This feels like registering an interest in aliases and alias changes. Calling GetAliases is an explicit "yeah, hit me" kind of thing. However, calling GetContactAttributes on your contact list with Aliasing in the interface list doesn't feel like the same thing to me, so I'm inclined to say the contact attribute *shouldn't* make an alias request. > GetLocation states almost the same, but GetClientTypes and GetContactInfo > doesn't. Should we armonize this? Same thing for Location. Contact client types are discovered when you disco a contact, which you do anyway, so that's not a problem. And do we get the contact's vcard anyway too? I can't remember. But yes, it feels like > In XMPP, requesting the alias means fetching the vcard with avatar, right? Do > we really want that? Perhaps this answers my question. However if we're getting the vcard for contact's contact info, then we also have the alias and avatar and...? but not location.
Comment 5 Xavier Claessens 2012-05-18 06:15:58 UTC
To summary: im.telepathy1.Connection.Interface.Aliasing1/alias: If unknown, fallback to id, and start the request. im.telepathy1.Connection.Interface.ClientTypes1/client-types: If unknown, omit from attributes, and start the request im.telepathy1.Connection.Interface.ContactCapabilities1/capabilities If unknown, omit from attributes im.telepathy1.Connection.Interface.ContactInfo1/info: If unknown, omit from attributes, no request started. im.telepathy1.Connection.Interface.Location1/location: If unknown, omit from attributes, and start the request im.telepathy1.Connection.Interface.Presence1/presence: If unknown, fallback to (Unknown, "unknown", ""). I've made this differ from legacy GetPresences which was documented to wait until roster is fetched. I think that now that we have a proper ContactList iface with ContactListState, clients knows when to expect a proper presence. I'm wondering if we should remove all those implicit requests, and use a client-interest for them (alias, client-types, location).
Comment 6 Xavier Claessens 2012-05-18 06:20:02 UTC
To complete the summary, in bug #33410 I've made: im.telepathy1.Connection.Interface.Avatars1/avatar-uri: If unknown, omit from attributes, no request started but AvatarsNeedRequest signal is emitted which looks silly in regard to what all others ifaces does.
Comment 7 Jonny Lamb 2012-07-13 10:39:15 UTC
The patch generally looks fine I think. There are a lot of English problems to fix up, but I'll do that after you merge it.
Comment 8 Jonny Lamb 2012-07-13 10:40:28 UTC
(In reply to comment #7) > The patch generally looks fine I think. There are a lot of English problems to > fix up, but I'll do that after you merge it. Oh yeah, I obviously ignored the Avatar stuff at the beginning of the branch.
Comment 9 Xavier Claessens 2012-09-06 12:32:49 UTC
Ok merged my branch. See comment #5 for the remaining question. In addition to that, the new avatar spec landed: im.telepathy1.Connection.Interface.Avatars1/avatar-uri: If unknown, omit from attributes, no request started.
Comment 10 Xavier Claessens 2012-09-10 14:02:43 UTC
Ok, after discussion on IRC, we agree that those are the correct behaviour. It's nicer to auto-request, but for contact-info we shouldn't because it's expensive. Closing.