Pedro Melo wrote: > > On Apr 4, 2008, at 9:04 PM, Dave Cridland wrote: >> On Fri Apr 4 15:55:26 2008, Philipp Hancke wrote: >>>> If we solve scalability in MUC and PubSub - and I think we can >>>> *without* repeaters, and I think that repeaters are not well >>>> understood, and may cause greater harm than good - then I think this >>>> is way beyond good enough. I believe that for both MUC and PubSub, >>>> using a slave entity which passes on subscriptions to a master >>>> entity, and manages >>> may pass on for "open" nodes ;-) >> I think MUST at all times. >> >> First off, open nodes should get the statistics. This is arguably a >> political choice rather than technical, but I suspect that if a feed >> publisher knows there are several million subscribers, they'll make >> more effort in their XMPP strategy. >> >> There is the technical argument that is that the policy of the node >> should be handled by the node, and not by a proxy. > > Sure, but if a node owner is ok delegating the subscriber policy to the > remote proxies, why should a future spec prevent that?
How do I know that a subscription request comes from a proxy? Does my pubsub service need to send a disco#info request to each subscriber in order to determine its identity, then ask me to approve the subscription request if it comes from a proxy? > Better: when I send a message to a remote proxy I could ask for a > "delivery report" message back, stating how many JIDs the message was > resent to. > > So I can get one report per message I send and keep my bean-counters > happy. I know the reach of each message. > > 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. >> A full solution to its woes would be essentially indistinguishable for >> Stanza Repeaters, so there's little point in doing so, but anyway, the >> point is that these three cases are not actually as similar as one >> might hope, and the case that has the highest cost in terms of >> complexity is also the one which has the lowest gain. > > Yes. I agree with this. > > And although its always nice to solve a lot of problems with a single > XEP, I would like to see the pubsub problem solved first, at least for > the public node scenario. I think that the experience we can get by > solving that will be useful to attack the others. 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. 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. Generalized solutions are appealing, but there's always the danger of over-generalizing. 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 nodes. Send to the bot or proxy and it distributes messages on the remote end. You can even chain those together. Granted we might want more elegant solutions, but these might be enough to get the job done for a while. Another approach: when you try to join a room or subscribe to a node, you are redirect to the local slave/proxy. We'd need better support for the redirect error but that seems doable. Still pondering... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
