[Standards] Entity Capabilities Woes

Daniel Noll daniel at noll.id.au
Fri Mar 16 15:11:57 UTC 2007


On Friday 16 March 2007 08:09, Peter Saint-Andre wrote:
> > I can sense this causing a headache further down the track.  Some client
> > will put in an "ft" feature for file transfer on version 1.0, and then in
> > version 2.0 they will add Jingle support.  Clients who happen to query
> > version 2.0 first will cache that "ft" means Jingle FT, and then
> > interesting things will happen when they encounter a version 1.0 client.
>
> That's a different feature, so the client author should change the name
> of the extension.

Is it really a different feature though?  The checkbox the user checks calls 
it exactly the same thing.  It seems crazy to check one checkbox and actually 
have it enable two extensions (waste of traffic.  What if we end up with more 
than two ways of doing file transfer in the future?  Are we going to send 10 
ext values just because the user checks one checkbox?)

> > It seems like it would be easier for everyone (except disk space, which
> > is cheap anyway)
>
> Not for web clients or mobile devices. :)

Bull.

1. Web clients not only have more disk space than we do because they run on a 
server, but they are also able to cache the disco features across multiple 
users' sessions, something a desktop client can't even dream of doing.

2. You might not have noticed that a 1GB Secure Digital card costs around $10 
now.  Not to mention that there are many phones on the market which offer 
similar or larger amounts of built-in memory before even adding a card.

> > if it were assumed that ext is completely free of semantics.
>
> All we're saying is that node#ext is stable. I don't know if I would
> call that semantics.

Stability is a semantic of course.

But I guess it's almost workable, as long as you mean the *combination* of ext 
is stable.  If you mean that each individual ext value always maps to the 
same disco features, that will result in confusing situations.

  e.g. client sees someone with ext="a b", features "A, B, C".
       client sees someone with ext="a", features "A, C".
       client sees someone with ext="b", and assumes that features="B" when it
           may in fact be "B C".

I suppose the problem only occurs with subtraction though, so a client could 
happily assume that adding a new ext won't do anything unexpected.

Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070317/1e8abeef/attachment.sig>


More information about the Standards mailing list