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