[jdev] Gaim and gnomemeeting using jabber

[Tijl Houtbeckers]

On Fri, 3 Dec 2004 15:07:27 -0700, Peter Millard <pgmillard at gmail.com>  
wrote:

> On Thu, 02 Dec 2004 19:39:06 +0100, Tijl Houtbeckers
> <thoutbeckers at splendo.com> wrote:
>
>> 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.
>
> Can you please provide an itemized list of the jeps which are in
> "waiting for disco" mode?

Well, it's not an official status for JEPs. Neither is "waiting for  
PubSub" by the way ;). I do however think there are many JEPs awaiting  
further work, or awaiting implementation feedback, because there is no way  
to really work with all the features yet. If you'd magically implement all  
the JEPs out there you'd see a lot of disco request going around,  
defeating the purpose of 115. A lot of experimental ones, but also some  
DRAFT ones (for example Ad-Hoc Commands) still suggest making those large  
disco requests.

That's why I raised the questions:
>
>> 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)
>
> What are you talking about? 115 does not superscede Disco in any way
> shap or form.

All I said is there is a relation between the two, in no way did I suggest  
by that it superscedes disco!

I'm just trying to come to grips with what will be the impact of more  
protocols in the future using 115. Which, even though they don't seem to  
mention it now (can you name me one? I don't read every single update of  
every JEP), they logically will have to in the future, cause it takes just  
one feature that needs a disco request to every client and it deafeats the  
purpose of having 115. Except ofcourse for it's "push" functionality (like  
in the VoIP) case, but we all know it's that very same feature that could  
get us swamped with unwanted presence packets. Which is the very reason  
we've told many folks on this list to "use pubsub instead". Which, for  
some reason I haven't heard of yet, did not happen 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?
>
> JEP-115 _IS_ the optimized way to use presence to discover stuff.
> Thats the whole point.

Yes, to "discover stuff". Unfortunatly that's not all we do in the Jabber  
World. I know I suggested it myself in this thread, but consider what will  
happen if 115 is used for telling whether VoIP is enabled in my client.  
This means you will get a presence packet from me, every time I receive a  
call. If your client does not have VoIP, is that a good thing? Will you  
still be a happy man if you look at your XML console and see me get a new  
call every 5 minutes?

This is why I'm curious about other disco using protocols (and future  
protocols) that have no mention of 115 currently.. but perhaps will/SHOULD  
use it, and their impact on the use of 115. And of course, what we could  
do about it.. (and see whether that's enough).

One server optimization I can think of it that a server only sends me  
updates on features that appear in my own "ext-list". So if I don't  
advertise "voip" I don't get any updates on it either. This of course,  
goes against the current spec ("The server MUST also ensure that any  
changes in the annotation (typically in the 'ext' attribute) are sent to  
all subscribers."). With some effort maybe you could even optimize the S2S  
traffic.

If you'd have this optimization in place though, my mind would start to  
wander a little more. So here we have an infrastructure where we push  
information to the users using presence, optimized so that it only goes to  
those users that want to receive it. Currently we can send "on" and "off".  
What if we could also send a small parameter.. let's say... the hash of an  
image file for your avatar? Or other "kind of" presence related data?  
Maybe even a small XML fragment telling your public geoloc? I don't think  
you meant those thing when you said "discover stuff"... if so how do you  
suggest I would do them?

It's sure no PubSub; no gap filling (history), no acces control, not even  
any garantue of delivery.. but what if you don't *need* all those things?

Perhaps this makes clearer why I'm wondering what the decision are behind  
letting 115 use presence instead of PubSub. I want to know why those would  
or would NOT apply to some other protocols. Perhaps we can bring back  
together the eXtendable and Presence in XMPP again. Or maybe it's just  
another bad idea :)