Rachel Blackman wrote: >>>> <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 >>> >>> "If the name string contains the version string..." >>> >>> strcasestr(clientname,version) == 1 >> >> But how do you know what a version string is? Just lots of fancy regexes? > > name='Exodus 0.9.1' > v='0.9.1' > > strcasestr("Exodus 0.9.1","0.9.1") == 1 > > "Oh, they included the version in the client name information. I'll > just use the name without appending." > > :) > >>> If we aren't adding version into presence, that's another thing, but I >>> would expect that users will request this -- showing what version of a >>> client the other person is on has been one of our own most-common >>> requests. >> >> Well, the sense I got from the list discussion is that end users want to >> know what client the other person is using, but don't necessarily need >> or want to know which version of the client is in use. >> >> Did I misinterpret the list discussion? > > Not necessarily; I'm just noting from personal experience that users do > want the version information too. There's no logical reason for it, and > it may be a deal-breaker, but it's always something that gets asked for > if I omit it. :) > >>> I agree there is no solid engineering reason for it, but it is >>> functionality clients presently can have, and removing functionality >>> will always generate end-user bug report/feature request tickets. And >>> sometimes features are driven by 'what users want' rather than by any >>> solid engineering goal. (Is there a real engineering benefit to >>> avatars? No, but users demonstrably wanted them.) Just my $0.02, >>> though. :) >> >> I don't disagree with that. >> >> So are you in favor of the 'v' attribute? I really don't care at this >> point, and I don't want to remove functionality, and I don't want to go >> back to the bad old days of the version flood. So if the little 'v' >> attribute saves the day, I'm +1 to that. > > I'm fine with the v. I still think that using version as it was before > and then including a new forward-compatibility hash operator would've > made more sense, as it would then continue to work with everything. > > New clients would use the hash field and could validate against that, > old clients could still query as before AND use the ver field for > display. Our newer method means we break backwards compatibility, as > older clients will show the hash as the client version string (and may > not be able to query against node#hash to cache, given the 1.4 > recommendation that you just query with no disco node), and newer > clients need to be able to determine if the ver string is a hash (and > thus something they can validate against) or an old-style version (and > thus something they need to query), and whether or not they can display > it (old-style) or need to use the 'v' attribute, and so on. > > I.e., I think this method is kind of a mess, when just adding 'hash' in > separately would've solved the backwards compatibility issue nicely. > However, that ship has probably sailed, so even just including 'v' will > solve the 'users will ask for this' concern I had about displaying > version strings. :)
Er, yes. We should've listened to Jacek Konieczny years ago. Unfortunately we didn't, so we're in a bit of a fix now. So I've added the 'v' attribute. Updated version: http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html Diff from 1.5pre8: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1403&r2=1409 Diff from 1.4: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=1409 Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
