OK, I'm still trying to get to closure here... :) Rachel Blackman wrote: >> A version is only interesting if you know the software that it goes with. >> Unfortunately all we have is a URI, which means for any sane display I >> need a >> table of URI->"software name" mappings, and thus I can only display >> versions >> for software I know about. That seems limiting. > > Not really; you can just cache the identity part of a disco query when > you cache the list of features. Usually the identity contains the > client name, and you are already generally getting that when you do your > disco query. In general, I see things like... > > <identity category='client' name='Exodus' type='pc'/> > > ...coming back. You cache the name, and add the version. (Optionally, > if the name string contains the version string, a'la 'Exodus 0.9.1' and > version '0.9.1' you just use the name unmodified.)
Hmm. What if you have this? <presence from='[EMAIL PROTECTED]/orchard'> <c xmlns='http://jabber.org/protocol/caps' node='http://code.google.com/p/exodus/' v='0.9.1' ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/> </presence> AND... <identity category='client' name='Exodus 0.9.1' type='pc'/> Then do you display the following? Software: Exodus 0.9.1 0.9.1 [sic] That seems bad. Let's keep the version information in one place. I think it's safest to put it in the disco#info 'name' attribute and nowhere else (that is, if people really want this information -- the more I think about it, the less convinced I am that it is useful or important to provide the version information in caps). This way we don't clog up the caps data with version information, we don't need to add a new 'v' attribute to caps, and we can leave the naming to disco as it (perhaps) should have been all along. > Granted, this becomes an issue if you have two clients with identical > hashes but different names, so Justin's suggestion of an 'n' field in > the caps is not without merit. But users do like this information -- > and it can be useful to know that someone is on the Gmail web client, > rather than Google Talk itself -- so having SOME way to convey it in a > sensible and bandwidth-efficient manner (i.e., avoiding our old-school > iq:version flood) is a good idea. Well, as Justin said, a client can maintain a mapping of node -> name (derived from disco#info results) if it really cares, right? Then if you want to advertise different builds of the same or similar client, you could include different nodes (http://www.google.com/talk/win vs. http://www.google.com/talk/web or whatever). So folks, let's keep things in perspective: 1. What really matters here is the capabilities (in 1.4+, the 'ver' attribute). 2. The node is nice to have for certain use cases because it can give you a mapping to a client name (via disco#info) if you want it. 3. The version information may be desirable in certain odd situations, but I have not heard a compelling argument for it (most people want to show the software name but are not all that interested in the exact version). If you really really need the version, use XEP-0092 (but for Pete's sake don't flood every person in your roster for the damn version because no one really cares about it!). Therefore I argue for removing version from caps (i.e., not adding it back in version 1.5 -- we already removed it from 1.4). An updated copy (1.5pre8) of XEP-0115 is here: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html The SVN diffs are here: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1403 Do we have consensus? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
