[Standards] Council on Stanza Repeaters without Multicast

Pedro Melo melo at simplicidade.org
Tue Apr 8 16:09:36 UTC 2008

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?

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.

> 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.

Best regards,
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org

More information about the Standards mailing list