Bug 43035

Summary: A method to avoid downloading the roster at every connection
Product: Telepathy Reporter: Alban Crequy <alban.crequy>
Component: tp-specAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: andrunko, marco.barisione
Version: unspecifiedKeywords: patch
Hardware: Other   
OS: All   
URL: http://cgit.collabora.com/git/user/alban/telepathy-spec.git/log/?h=roster
Whiteboard: review+
i915 platform: i915 features:

Description Alban Crequy 2011-11-17 10:45:40 UTC
On XMPP, the roster is not sent automatically by the server to the client: the client has to explicitly request to download it. At the moment, gabble always downloads it as soon as the connection to the server is established. It uses bandwidth and it would be better not to download it too often. Possible reasons:

- The UI does not show the roster, so we don't need to download it,
- The UI could cache the roster and could be ok with less regular updates,
- The UI has an out-of-band method to get the roster.

We can have a connection parameter specifying whether to download the roster on startup, and a new method on the connection to explicitly request the download when needed.
Comment 1 Guillaume Desmottes 2011-11-21 00:38:53 UTC
We have to think about we'll integrate this with MC as that's the one connecting the connection. And possibly also with Folks as most apps will rely on it to get the roster.
Comment 2 Simon McVittie 2011-11-21 03:22:15 UTC
While implementing client interests and ContactList I wondered whether ContactList should be a client interest that's automatically added by calling any ContactList method, but other spec developers thought this was unnecessary.

Be aware of this bit from RFC 3921 §7.3: "If an available resource does not request the roster during a session, the server MUST NOT send it presence subscriptions and associated roster updates."

If we get presence in its role as contact-list change notification, or a roster push, then we should probably download the contact list automatically at that point, as an attempt to resync. (The above means that only buggy servers can cause that situation, I think - but it wouldn't surprise me at all if semi-XMPP bridge-based servers like Facebook and Windows Live don't obey §7.3.)

Would XEP-0237 Roster Versioning remove the need to avoid downloading the roster? (I don't know which servers support 0237, though, and I suspect that it's the big, popular ones - like GTalk and Facebook - that are least likely to do so.)
Comment 3 Alban Crequy 2011-11-21 05:46:50 UTC
(In reply to comment #2)
> Be aware of this bit from RFC 3921 §7.3: "If an available resource does not
> request the roster during a session, the server MUST NOT send it presence
> subscriptions and associated roster updates."
> 
> If we get presence in its role as contact-list change notification, or a roster
> push, then we should probably download the contact list automatically at that
> point, as an attempt to resync. (The above means that only buggy servers can
> cause that situation, I think - but it wouldn't surprise me at all if semi-XMPP
> bridge-based servers like Facebook and Windows Live don't obey §7.3.)

Ok...

Both GTalk and Facebook don't obey §7.3. and send the presence notifications anyway: I see the presence changing in the Empathy chat window even when roster requests are disabled in Gabble.

> Would XEP-0237 Roster Versioning remove the need to avoid downloading the
> roster? (I don't know which servers support 0237, though, and I suspect that
> it's the big, popular ones - like GTalk and Facebook - that are least likely to
> do so.)

Yes, XEP-0237 would be good but GTalk and Facebook don't support it.
Comment 4 Alban Crequy 2011-11-22 07:17:23 UTC
(In reply to comment #2)

> Be aware of this bit from RFC 3921 §7.3: "If an available resource does not
> request the roster during a session, the server MUST NOT send it presence
> subscriptions and associated roster updates."

RFC 3921 is obsoleted by RFC 6121 and that bit was removed and replaced by the following explanation.

RFC 6121 §4.4.3: "Upon receiving presence from the user, the contact's server MUST deliver the user's presence stanza to all of the contact's available resources."

Where "available resource" is defined by §2.2: "After a connected resource sends initial presence (see Section 4.2), it is referred to as an available resource."

This is orthogonal  to an "interested resource": "If a connected resource or available resource requests the roster, it is referred to as an interested resource."


So I would say the new RFC helps us :)
Comment 5 Alban Crequy 2011-12-14 10:57:15 UTC
I added a patch on the spec (see the URL field on this bug), and filed bugs with patches on telepathy-glib (Bug #43826) and gabble (Bug #43828).

On this spec patch: should I put the changes in a separate Conn.I.ContactList.FUTURE interface first?
Comment 6 Andre Moreira Magalhaes 2011-12-20 09:06:36 UTC
Here goes a first review, but I would prefer if some spec developer could check it also.

I was wondering if we should state in the spec that CMs MUST default to true on DownloadAtConnection to avoid breaking existing clients. Imagine that gabble or other current CM starts supporting this property but defaults to false. It would break all existing clients that don't call ContactList.I.Download().

+ <tp:rationale>
+ <p>Downloading the contact list uses bandwitdh and it is not always
+ necessary: the UI may not need to show the contact list, the UI
+ could cache the contact list from previous connections and accept
+ less regular updates, or the UI can get the contact list from an
+ out-of-band protocol-specific way.</p>
+ </tp:rationale>

I think this rationale is a bit confusing, maybe 
"Downloading the contact list uses bandwitdh and is not always
necessary or desired. For example, a client could cache the contact list from previous connections and accept less regular updates, or it could get the contact list from an out-of-band protocol-specific way, or even don't need contact lists." ?
Comment 7 Jonny Lamb 2011-12-21 07:13:26 UTC
(In reply to comment #6)
> I was wondering if we should state in the spec that CMs MUST default to true on
> DownloadAtConnection to avoid breaking existing clients. Imagine that gabble or
> other current CM starts supporting this property but defaults to false. It
> would break all existing clients that don't call ContactList.I.Download().

Sounds sensible to me.

> + <tp:rationale>
> + <p>Downloading the contact list uses bandwitdh and it is not always
> + necessary: the UI may not need to show the contact list, the UI
> + could cache the contact list from previous connections and accept
> + less regular updates, or the UI can get the contact list from an
> + out-of-band protocol-specific way.</p>
> + </tp:rationale>
> 
> I think this rationale is a bit confusing, maybe 
> "Downloading the contact list uses bandwitdh and is not always
> necessary or desired. For example, a client could cache the contact list from
> previous connections and accept less regular updates, or it could get the
> contact list from an out-of-band protocol-specific way, or even don't need
> contact lists." ?

This sounds a little clearer, but is basically the same thing. Just a few English nits fixed here:

Downloading the contact list uses bandwidth and is not always necessary or desired. For example, a client could cache the contact list from previous connections and accept less regular updates, it could get the contact list from an out-of-band protocol-specific way, or it could not need the contact list at all." ?

Let's just leave this in the core interface for now.
Comment 8 Alban Crequy 2012-01-03 07:15:15 UTC
I updated the branch:
- explanation reworded
- add default to true
- remove error NotAvailable in Download() because the spec says Download() does nothing when the property is true.
Comment 9 Andre Moreira Magalhaes 2012-01-03 07:22:05 UTC
(In reply to comment #8)
> I updated the branch:
> - explanation reworded
> - add default to true
> - remove error NotAvailable in Download() because the spec says Download() does
> nothing when the property is true.

Looks good to me, but as I said I would rather double check with a spec developer.
Comment 10 Jonny Lamb 2012-01-03 10:24:06 UTC
Yeah, looks fine to me now.
Comment 11 Alban Crequy 2012-01-04 05:58:03 UTC
Thanks for the review. Pushed on git master:

commit 3431c955686062c3798c30213a468d4f79be8544
Author: Alban Crequy <alban.crequy@collabora.co.uk>
Date:   Thu Dec 8 18:20:18 2011 +0000

    ContactList: add DownloadAtConnection property and Download method
    
    https://bugs.freedesktop.org/show_bug.cgi?id=43035
Comment 12 Alban Crequy 2012-02-23 05:33:25 UTC
For the record, this is included in telepathy-spec 0.25.2.

- The bug for telepathy-glib is Bug #43826
- The bug for telepathy-gabble is Bug #43828

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.