[Standards] Entity Capabilities Woes

Rachel Blackman rcb at ceruleanstudios.com
Fri Mar 16 16:57:02 UTC 2007


>> 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?)

Yes, from a PROTOCOL STANDPOINT, they are absolutely different  
features.  The user isn't seeing what the ext values are (unless  
they're examining the raw XMPP stream), but the other clients are  
sure as hell going to notice a difference.

For Astra, where I'm implementing both file transfer, I'm only having  
one 'file transfer' button or menu option.  If the other side  
supports the new Jingle FT, I use that.  If they support the old- 
style FT, I use that.  The actual /user/ doesn't need to know the  
difference, just whether or not they can send a file.  But the other  
client absolutely must know the difference.

Saying that because both are file transfer protocols they are the  
same feature is like saying that because AIM and XMPP are both  
messaging protocols, I can advertise them as one messaging network.   
Maybe from an end-user standpoint they look similar, but under the  
hood they are vastly different.

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

Each individual node#ext value always maps to the same disco  
features, yes.

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

No, it does not.  BY THE XEP, the results returned by a disco query  
to a full node#b pair should always be the same.  If the client  
changes them, that is a bug and they get to live with the  
circumstances.  Just like if I decide that I want to send something  
non-standard in XHTML-IM... I can do it, sure, but then I don't get  
to complain other clients aren't interacting with mine right because / 
I/ didn't meet the spec.

You cache the results of each element separately, and then combine  
them to create a union of features based on what each client tells  
you.  So subtracting an element shouldn't hurt, either; it just means  
you don't use those cached features when assembling the capabilities  
for a client that sent you caps info.

Further, the ext only has meaning within a client, and if you really  
want to change your entire meaning, you change the node that caps  
queries should be disco'd against.  To use your example:

node='http://example.com/client/caps' ver='0.8' ext='a b'

...then I query the client with http://example.com/client/caps#0.8  
and cache that, as well as querying http://example.com/client/caps#a  
and http://example.com/client/caps#b -- each is an individual disco  
query.

Now when I see:

node='http://example.com/client/caps' ver='1.0' ext='a c'

...I don't have http://example.com/client/caps#1.0 or http:// 
example.com/client/caps#c cached, so I query those.  I /do/ already  
know what http://example.com/client/caps#a maps to (from the earlier  
query), so I just use the cached value.

If, of course, I see some other client:

node='http://sample.org/xmpp/caps' ver='2.1' ext='a'

...then I need to now query and cache http://sample.org/xmpp/caps#2.1  
and http://sample.org/xmpp/caps#a because 'a' here does not in any  
way, shape or form necessarily map to the 'a' above.

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list