[Standards] Entity Capabilities Woes
kevin at kismith.co.uk
Fri Mar 16 15:27:01 UTC 2007
On 16 Mar 2007, at 15:11, Daniel Noll wrote:
> On Friday 16 March 2007 08:09, Peter Saint-Andre wrote:
>>> I can sense this causing a headache further down the track. Some
>>> 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
>>> version 2.0 first will cache that "ft" means Jingle FT, and then
>>> interesting things will happen when they encounter a version 1.0
>> That's a different feature, so the client author should change the
>> of the extension.
> Is it really a different feature though?
Are they defined in different XEPs? You may amalgamate them into a
singe meta-feature for the UI, and that's fine, but protocol-side
(which is where we're sitting at the moment) they're completely
> The checkbox the user checks calls it exactly the same thing.
Writing UIs which exactly map onto the semantics of a protocol or
data-store is one of the most famous ways of writing Really Bad UIs™
so I don't think this is a major sticking point.
> It seems crazy to check one checkbox and actually
> have it enable two extensions
It doesn't - see above.
> (waste of traffic. What if we end up with more
> than two ways of doing file transfer in the future?
Well, most likely filetransfer is something that's not going to
belong in an ext anyway, but that aside we're not talking about any
noticable amount of bandwidth - and you argue below that resources
are plentiful anyway.
> Are we going to send 10
> ext values just because the user checks one checkbox?)
Having three file transfer protocols on the table at the moment is
something we're trying hard to fix; 10 equivalent file transfer
methods really would be a failure of council. However, if it's some
'enable extended features' checkbox, sure 10 features = 10 features.
Psi XMPP Client Project Leader (http://psi-im.org)
More information about the Standards