...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
"If the name string contains the version string..."
strcasestr(clientname,version) == 1
Thus, you just use 'Exodus 0.9.1' (the name field) since the version
string is a substring of the name. I agree it's not necessarily
ideal, but this is how many of us deal with things ANYWAY when sorting
out version information.
I still think, regardless, if we are adding version into presence, it
is silly to kill the old ver field, then put the value into a new v
field. 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.
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. :)
--
Rachel Blackman <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
