Hi,
On Apr 9, 2008, at 12:35 AM, Peter Saint-Andre wrote:
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?
No. the local-proxy to origin-pubsubs subscription request is tagged
with a "hey, this is a proxy subscription, I will rebroadcast your
notifications to local subscribers"-namespace.
The origin-pubsub service can opt not to allow proxy subscriptions,
of course, and in that situation the user should send the request
directly to the origin-pubsub service.
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.
Given that the local subscription list at the local-proxy can change
between notifications, the origin-pubsub-service might want to know
his reach per message. I personally would not use this in a very
active topic, but for things like blog updates-over-pubsub, it should
be ok.
Again, its optional, and under the control of the origin-pubsub
service either at subscription time or per notification.
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.
Agreed. I just don't feel confortable discussing MUC because I have
very little experience with large-scale MUC settings.
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.
Until we understand all the privacy-list restrictions on presence, I
wouldn't either.
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.
As should be obvious by now, I like local pubsub services acting as
proxys for remote pubsub services public nodes.
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.
That's what I've been writing these past two weeks: you, the client,
subscribe to a remote pubsub node, using your local pubsub service as
a proxy. The second subscriber doesn't even need to bother the remote
pubsub service.
Unless you mean that the redirect is "invisible to the user"... Like
a transparent HTTP proxy. If thats the case, you should at least
cache negative subscription-by-proxy responses.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
