On Thu, 02 Dec 2004 19:39:06 +0100, Tijl Houtbeckers <[EMAIL PROTECTED]> 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 :)
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mail.jabber.org/mailman/listinfo/jdev
