[Standards] XEP-0115 redux

[Peter Saint-Andre]

Dave Cridland wrote:
> On Thu Jan 17 18:08:54 2008, Kevin Smith wrote:
>> I confess that I'm starting to wonder what the difference is between
>> iq version floods and presence floods when you log on.
>>
>>
> I thought about this, too.
> 
> Let us suppose a user with N contacts in the roster who are online at 
> the moment the user comes online. With a presence-based versioning 
> system, you're looking at N inbound, 1 outbound. (That's stanzas, of 
> course)
> 
> With an iq based system, you're looking at 2*N outbound, 2*N inbound, 
> since for every online buddy, you send one iq:version to them, they send 
> one to you, and you both return results.
> 
> So it's actually 4 times the number of stanzas, plus one additional RTT. 
> (I think - I've not given RTT counts much thought, I admit).

That's true *on login*.

But if my presence session is 8 hours long and I change my presence 3 
times an hour and I include the version information every time, the 
bandwidth consumption adds up. At that point the version flood starts to 
look better than putting this in presence.

Plus the name+os+version doesn't change during the course of a session, 
as service discovery features might (enable plugin, etc.). So it's not 
really related to communication capabilities.

>> > Honestly, I think the best bet is an optional n='whatever' as a
>> > display name in the caps field; takes up very little additional space,
>> > and if it's there you use that for a display.  That can say 'MyClient'
>> > or 'MyClient 1.0 (Win32)' or whatever.  You just use the string.
>> > Otherwise, you just don't query.
>>
>> The string seems fine, although we probably don't want to mandate not
>> querying, since clients may withhold it from global presence, but let
>> some people iq:version.
>>
>>
> I'm in broad agreement with this.

But n='Psi' doesn't tell you the OS (Psi is a multi-platform client) or 
the version (are you using 0.10 or the super new 0.11?). And it seems 
that end users love that feature.

>> > I do agree that this bit can be pulled out of the caps discussion at
>> > this point, though; the only bearing it had on caps was that
>> > previously the node#ver values of the original caps meant that you
>> > could map that to a specific disco#info identity string as well, so
>> > the functionality had (unintentionally) rolled into the old caps.
>>
>> I think it's pertinent in as far as if it drops from caps, the
>> replacement needs to appear at the same time, but other than that,
>> sure.
> 
> I have a vague feeling that we need to consider both issues together.

Well we're almost there, we could just put everything in caps and be 
done with it:

<presence from='romeo at montague.lit/orchard'>
   <c xmlns='http://jabber.org/protocol/caps'
      hash='sha-1'
      n='Psi'
      node='http://code.google.com/p/exodus'
      os='PPC Mac OS X Mach-O'
      v='0.11'
      ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>

What's a few more bytes between friends? ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080117/63a24c8c/attachment.bin