[Standards] Entity Capabilities Woes

Olivier Goffart ogoffart at kde.org
Sat Mar 17 11:19:23 UTC 2007


Le samedi 17 mars 2007, Daniel Noll a écrit :
> On Saturday 17 March 2007 14:10, Peter Saint-Andre wrote:
> > Why??? Just make each ext mean the same thing and change the ext string
> > if the feature changes. Better to change the ext string than the node
> > string!
>
> I didn't like the idea of having to invent N ext strings for N
> protocol-level features, basically.


Remember that an ext string is not supposed to be human readable, so any 
random string is good.

You may also just append a version number to the string. 
Example "ft" for filetransfer,  and if you change it, call it "ft2"

And don't forget that most of feature can be in your client as base, not as 
extention.

> If you're going to keep the meaning of an ext string over multiple versions
> of one application, you might as well share it across all applications and
> save even more space in the cache. 

Not possible, because of possible conflicts you know.

> It's true that we might have namespacing issues when two people invent a
> custom extension at the same time, but we already have that problem right 
> now if two people develop a plugin for the same client and happen to name
> their ext string the same.

Yes that's right.  The client author should write a policy for the ext usage 
in their plugins, but it's a policy internal to the client.

> Or is it possible to have multiple top-level 
> cap containers so that plugins can namespace themselves away from the
> namespace of the client's caps?

Of course, an ext could be a kind of namespace.
node='http://sample.org/xmpp/caps' ver='2.1' ext='a b http:plugin.com:xmpp:ft'
(I just think that / is not allowed in the ext name)



Really, i think that XEP-0115 is good, I think that you just fail to 
understand the exact meaning of the ext attribute.
let's quote the XEP (§4.1)
| The names of the feature bundles MUST NOT be used for semantic purposes:
| they are merely identifiers that will be used in other use cases.  
 
-------------- 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/b9ed7a8b/attachment.sig>


More information about the Standards mailing list