[jdev] Gaim and gnomemeeting using jabber
thoutbeckers at splendo.com
Fri Dec 3 17:18:34 CST 2004
On Fri, 3 Dec 2004 15:07:27 -0700, Peter Millard <pgmillard at gmail.com>
> 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
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
>> 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
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 :)
More information about the JDev