<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. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
