[Standards] XEP-0115: version 1.5 revisited

Rachel Blackman rcb at ceruleanstudios.com
Tue Nov 20 19:38:03 UTC 2007


>>> <presence from='romeo at montague.lit/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. :)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list