[jdev] Gaim and gnomemeeting using jabber

[Tijl Houtbeckers]

On Thu, 2 Dec 2004 17:46:40 +0100, Ralph Meijer <jabber.org at ralphm.ik.nu>  
wrote:

> 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?