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: [EMAIL PROTECTED]
Use XMPP!
