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.
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.
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.)
(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.
(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 :)
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?
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." ?
(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.
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.
(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.
Yeah, looks fine to me now.
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
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.