[Standards] Entity Capabilities Woes
rcb at ceruleanstudios.com
Fri Mar 16 16:57:02 UTC 2007
>> That's a different feature, so the client author should change the
>> 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
> 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
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