Dave Cridland typeth: | again, it gives directed acyclic routing to MUC, which repeaters | don't do. (Well, I hope not).
My Multicast Repeaters suggestion does just that, but without the overhead of having MUC apps running on every node. Why do you hope Repeaters do not solve your problem? Two years ago you guys decided to bet on XEP-0033. This time you want to place your bets on IRC-like decentralized conference control? We've gone that path in PSYC before, and stepped back to a generic routing plan. Less likely to produce bugs. Since we don't have redundant subscription protocols the whole thing is a bit cleaner in PSYC. Whichever wheel you choose to invent, I don't know of any that hasn't already been driven. | I don't think we'll have a problem scalaing presence, because I don't | think it really needs to be scaled - it's neither low-hanging fruit, [x] You underestimate the problem. | It's certainly reasonable that we'd save a few stanzas by doing | something similar to repeaters or smart presence, but I think we'd be | saving perhaps 5 stanzas per presence burst, as opposed to several | thousand, potentially, per MUC or PubSub event. That's not | insignificant, but I'm far from convinced it's worth doing for that | sake alone. With typically over 70% of XMPP inter-server traffic being presence data[3], and close to 60% of it being redundantly transmitted[4], XMPP currently has a large overhead in delivering presence data to multiple recipients. New protocols are being researched to alleviate this problem. [3] http://mail.jabber.org/pipermail/standards/2006-May/011158.html [4] http://mail.jabber.org/pipermail/standards/2006-May/011182.html A few things may have changed since 2006, and of course there is more gain in MUC and pubsub, but you can't say that 50% protocol overhead is not a significant issue. | Maybe. But I'm far from convinced, and I'm concerned that a strategy | which attempts to convolve MUC, PubSub, and Presence scalability It would be a good idea to adapt MUC, pubsub and presence to use a common generic subscription model with multicast distribution, rather than figure out a different distribution strategy for each protocol application. | Incidentally, repeaters are simply a slightly more explicit, and | generic, model of smart presence, and the (then-) council dropped | that. The biggest difference is that Repeaters are proposed by people | well-known to the community, and that's not a particular useful | technical argument to me. (It does mean that there's a greater chance | that the proposal fits the XMPP model, as in this case, but it | doesn't make it automatically technically better.) Hehe. Nice to hear that from you. Anyway, it may have improved the council's understanding of the issue. So after being mislead by XEP-0033 this time around they have a new chance of taking a wiser decision. Of course there are things that can be improved about Repeaters, but the path you are heading out to is going to keep XSF busy for several more years until XMPP is actually a viable solution to the problems. Until then you will honestly have to admit, that large chatrooms and pubsubs are better done with IRC channels and bots (they don't have a nice XML structure, but they work up to close to a million participants), in case someone asks. You could also mention PSYC, which has nice structures and scales even better, but I bet you won't do that. | We know that compression+XEP-0033, for example, yields fewer stanzas | but greater bandwidth than compression alone. We know that "Smart | Presence" yields both fewer stanzas and less bandwidth, but fails to | match our model - I don't think it matches the model in its last | incarnation, and there's way too much handwaving in that protocol. Please define "handwaving" and mention the exact parts of the document that you would like to have modified.
