On 3/12/09 11:36 AM, Pedro Melo wrote: > > On Mar 12, 2009, at 4:16 PM, Peter Saint-Andre wrote: > >> Developers have been poking me about roster versioning: >> >> http://xmpp.org/extensions/xep-0237.html >> >> In fact developers are already implementing it. :) >> >> So we need to make a final decision: >> >> 1. Do we limit this to rosters? >> >> <iq type='get'> >> <query xmlns='jabber:iq:roster' ver='foo'/> >> </iq> >> >> Implications: (a) it is included in rfc3921bis (b) it can't be used for >> anything else (e.g. disco) and we'd need to define similar methods for >> those protocols. >> >> OR >> >> 2. Do we make it more general? >> >> <iq type='get'> >> <query xmlns='jabber:iq:roster'> >> <ver xmlns='urn:xmpp:dataver'>foo</ver> >> </query> >> </iq> >> >> Implications: (a) it is defined in a standalone XEP (b) it can be used >> in any protocol that might return large data sets (rosters, disco, and >> perhaps others). >> >> I still lean to #1 but let's get consensus and finish this discussion so >> that developers can do their coding. :) > > #1. > > The semantics of #1 work well for roster synchronization between server > and client. Nothing guarantees that they will work as well for other cases.
I tend to agree. > On a side note: For the disco situation, the hash-based caps work > already, and we could ask server vendors to send a server presence on > connect with their own caps. Caps to cache server disco#info might just > work. The problem to be solved is disco#items, not disco#info. E.g., you request all the chatrooms associated with a MUC service. Why receive all the rooms if no rooms have been created since you last logged in? And it would be nice to receive updates to the list as rooms are created and deleted during your session (otherwise you need to poll). But I agree that we don't have push semantics for disco as we do for rosters (unless servers implement something like XEP-0230). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
