Re: XEP-0115: version 1.5 revisited

On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote:

> 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.

I agree that it's unfortunate that old clients will show the
hash as  
the version number.  Like stpeter said, though, I'm not
convinced that  
the version number has general-purpose utility.

-- 
Joe Hildebrand

>> 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#some
string 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#some
string 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 <rcbceruleanstudios.com>
Trillian Messenger - http://www.trillianastr
a.com/

Joe Hildebrand wrote:
> 
> On Nov 20, 2007, at 12:38 PM, Rachel Blackman wrote:
> 
>> 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.
> 
> I agree that it's unfortunate that old clients will
show the hash as the
> version number.  Like stpeter said, though, I'm not
convinced that the
> version number has general-purpose utility.

I'm not either, but if 'v' is optional and end users love it
then I have
no objections.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/