Peter Saint-Andre typeth: | > This could be an option in the initial response to the subscribe request | > by the proxy or a per-message flag somewhere. | | I'd prefer it as a subscription option, because it's not *really* | something you care about for each message, I think.
D'accord. | I tend to agree that the most interesting use cases here are MUC and | pubsub. Now, you could argue that MUC is just a specialized form of | pubsub, but in reality it's different enough that we may need to handle | it separately. Since presence is causing those 47% overhead stanzas on the XMPP network, why are you postponing the #1 scalability problem of XMPP again, and put things first, which aren't even used *because* they don't scale? | Presence is just a specialized form of pubsub, too, as has been pointed | out many times before. But I'm not yet convinced that we need to tweak | presence much. Oh I see you follow our discussion a lot. | As I see it, MUC and pubsub already can be multicasted if you don't mind | having bots in your MUC rooms and pubsub services subscribed to pubsub Hey, clients are multicast points, too.. Yippie.. why don't you redirect onto some public ports of your clients? Then you can ask people to run clients just for the sake of setting up a multicast tree and everything is fine and you got away without a new properly designed interserver routing protocol, just a bunch of shaky band-aids. This scenario isn't even so out of this world.. it's what other people call P2P, but it shouldn't involve 3 different distribution mechanisms (muc + pubsub + resource "routing"). It should have a clean single multicast routing strategy that reaches all the way from the chatroom master down to hundreds of thousands of clients, if necessary. And if the routing protocol is clean enough, it doesn't matter if an intermediate node is a federation server or a P2P-acting client. It becomes a question of trust, which is up to the subscribing user to decide. If I trust the client of my friend sitting next to me, why not? Why transfer the same stuff over my network uplink twice, then? Concerning <redirect/> - I've had several situations where I wanted to automatically send clients elsewhere, but had to see that none of the clients implement <redirect/> that way, because nobody told them to. So you could do us a favor and write up a best practices for redirect while we think about fixing the scalability issue properly.
