Bug 50082

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?

The avatar iface is already taken care of in bug #33410

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.

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.

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

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.

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.

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

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.

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.