[Standards] Entity Capabilities Woes
rcb at ceruleanstudios.com
Wed Mar 14 16:02:53 UTC 2007
> A good hypothetical argument, but I don't think it's a huge practical
> issue. A number of reasons:
> * I haven't seen many clients doing a ton of proprietary stuff that
> needs caps. In general, not many new extensions are getting created
> on a
> yearly basis.
I would argue, however, that this ('not many new things happening')
is not a *desirable* state.
I think redesigning a protocol to account for that is not necessarily
the best idea. ;)
> * We could let people put whatever they want in the registry, even
> non-XEP entries. I don't think we'll run out of possible short name
I still think the caps values will get far larger than they are right
now. And I don't think we gain anything from it. Right now, caps
doesn't need to be rewritten whenever something new is added; caps
just plain continues to work.
I do agree that your method is perhaps simpler on the initial
implementation. I think your method is, however, harder in the
longer-term implementation. If, in other words, a new protocol comes
out under a temporary namespace (and heck, a temporary registered-
shortname), and I implement that, fine.
Then if it changes down the road, is promoted to draft, gets an
official namespace and an official shortname... under the current
caps system, all I need to do is add an additional check for the new
namespace in the appropriate code. All the caps caching, everything
else, just plain works. Under your system, I need to update a static
compiled-into-the-binary table of registered shortnames as well; one
more step. Not a difficult one, but still, one more step.
So it doesn't save bandwidth, and it doesn't really save work *in the
long run*, even if it lets a client author be lazy in the short
term. Given that a lot of clients implement caps as it is, I don't
know that the hypothetical benefits of this are worth the upheaval.
> * The benefits of the simpler protocol far outweigh the hypothetical
> problem. If there is a conflict, the client authors would likely
> it pretty quickly if it's a practical issue.
Honestly, I'm not sure that the protocol is that much simpler. Under
current caps, you still have a 'featureset to shortname' mapping,
it's just that the table is built dynamically. You still only need
query, say, http://gaim.sf.net/caps#chatstate or whatever once, and
I promise it isn't that hard to implement. :)
>> Sorry, but I just like to invent counterarguments ;) More
>> seriously: I really liked your (before it was "your")
>> proposal when it was first discussed here. But then I got
>> convinced that it works so well only on the paper, but not in
>> real life. At least this is my opinion.
> Well, we can't take credit for the idea. But, maybe it's a good sign
> that it keeps getting proposed. I would submit that the objections are
> more hypothetical than practical.
I think the objections are more that when someone sees something
close to a 'push' protocol (as caps sort-of is), they want all the
data pushed to them. It feels offensive on first glance, somehow, to
go out and have to request the data based on what you were given,
instead of just being given all the things you need. It seems to me
a psychological thing, and probably why it does get proposed
However, caps really, really is not that hard to implement if you
already have disco with node support. This method is flexible, not
terribly complicated, and it really doesn't generate that much in the
way of bandwidth goo. And honestly, if people think /caps/ is too
complicated, I can't imagine how we're ever going to get Jingle
In the end, caps is one of our protocols that is actually both a)
sufficient for the task, and b) reasonably well-adopted. Given that,
I think time and effort is better spent on other things (like sorting
out that we now presently have two completely incompatible file
transfer protocols!), rather than taking a wheel which works and
spending that time reinventing it just because you don't like the
tread pattern. :)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/
More information about the Standards