[Standards] Entity Capabilities Woes

[Rachel Blackman]

> 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  
> some
> non-XEP entries. I don't think we'll run out of possible short name
> values.

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

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

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  
adopted. :/

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/