[Standards] XEP-0115: version 1.5 revisited
rcb at ceruleanstudios.com
Wed Nov 21 17:37:46 UTC 2007
>> 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. :)
> And then new clients would need to respond to both new-style queries
> and old-style queries, as well as continuing to send ext for
My backwards-compatibility concern was less about version display in
this case and more about the use of that value.
Old style, if I had node='http://foo.com/bar' and ver='somestring',
then I could query on http://foo.com/bar#somestring and get that value
(and of course, same with the exts).
Now you are supposed to just do a straight out disco query against the
user; http://foo.com/bar#somestring is not guaranteed to actually be a
valid query you can perform, which means old-style clients that expect
to do node#ver queries may not receive data at all. Thus, we broke
backwards compatibility entirely.
Hence my thought that including node/ver if you wanted to support the
old style client queries, and including the hash differently if not,
would have been more backwards-compatible. My talk about version
display is just because I know users will ask for the version string,
not because I think it has any inherent value. I just always think to
myself 'will my users howl at me if I remove this,' and if the answer
is 'yes,' I speak up. ;)
But I think breaking the version string for a 'backwards
compatibility' which we then proceeded to break by removing the 'query
on the hash' aspect of things was not our best decision as a standards
body. Because at this point, we've managed to confuse the issue AND
ensure old implementations may not work, either. That's my concern
there; over the course of a few revisions, we made the protocol more
confusing, and then we sacrificed the backwards compatibility we
supposedly gained by that confusion.
I mean, I know how I will implement this (including generating my hash
and then allowing it as a proper disco query to allow old-style
clients to work with me), but the situation seems non-ideal. Given
that we broke with backwards compatibility by removing the ability to
query on the hash, we should have just kept node/ver with their old
meanings, and added a separate hash attribute.
Anyway, what's done is done; I point this out only to show that we
shouldn't let this happen again when changing other bits and pieces,
down the road.
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards