In one of your earlier messages you asked why caps (JEP-0115) was exempt from
the 'do not put stuff in presence' mantra. If I recall correctly, some clients
started sending iq:version requests to any contact that sent presence. While
this already produces an significatn amount of start-up traffic, we could
only wait for people sending elaborate disco requests instead, in an effort
to detect what the contacts' clients support.
Indeed pubsub was even less 'there' as now, so that wasn't a viable option at
the time. Also, there were some issues with group chats.
Presence is in fact a specialized pubsub implementation. So although it has
some of the nice properties that pubsub via JEP-0060 also has, it is really
only meant for distributing presence (as has been said many times in this
thread.
To have a simple solution to the problem, an exception for caps was made. But
careful thought was put into not sending to much stuff to all contacts.
The size of the caps annotations to presence was limited by requiring the
ext field to be a space separated list of capabilites, each identifier as
short as possible. Any additional information must be retrieved using disco.
There is also a section on server side optimization, to enable stripping redundant caps annotations from presence stanzas.
Hope this explains it a bit.
As I stated, I'm aware of all these reasons. However, they do not just apply to entity capabilities. According to the JEP version 0.1 dates to 2003-08-27. Version 0.1 of PubSub dates to 2002-11-19 (somewhere after Jabberconf Europe I believe). Many protocols that are currently in "waiting for PubSub" mode, and many of those date from way before 115 of even PubSub itself!
As I said, you won't find *me* telling you 115 is a bad idea. I'm just intrested in the reasons behind this decision and the rather quick acceptance of 115 to Draft, despite only having heard so far the same arguments for it that apply to so many other problems.
That for me raises a few more questions, that you'll perhaps find more intresting or challenging to answer.
Is it the intention to ever "move" 115 to pubsub or are there other arguments why it should stay the same way it is now other than "backwards compatible"?
If there are any such arguments, do they only apply to 115 and not other protocols, if so then why?
Since the intention of 115 is to prevent many disco requests being send, what about all those protocols that are currently stuck in "waiting for Disco" mode. Will 115 be enough to meet their needs? If so, do they already take 115 into account? If not, what should be done with disco? (Perhaps in relation to 115)
With hindsight, I think we could have benifited from a generic way to use presence in an optimized way, that would be easy to migrate PubSub if needed. Too late for that now.. or is it?
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mail.jabber.org/mailman/listinfo/jdev
