On Wed Apr 9 00:35:30 2008, 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?
I think the subscription request would be marked, to indicate that
the subscription request was from a proxy. This in turn suggests that
the proxy service needs to disco the master service. What I actually
see happening is:
a) Client sends initial request to an unknown service.
b) Local server intercepts this, and does disco to unknown service.
If it's a master-capable service, then the client's request is
modified to include a proxy.
c) Remote service responds - if this is a proxy request, and the
remote service doesn't wish to have it involved, it can say so at
this point.
d) Remote service sends out data, either to proxy service or to user
directly as required.
Note I've carefully avoided saying either of "MUC directed presence"
or "PubSub subscription" - the model itself applies to both equally,
although its implementation and syntax will differ.
What I'm particularly interested in is whether some of this disco can
be elided by the use of the feature-level XEP-0115.
> 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.
I'd have thought that, if the master is always aware of the numbers
of subscriptions, this is less important. It could be, though, that
errors are passed back.
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.
I think they are the same in most respects, but the syntax differs.
MUC+PubSub can be handled by the same protocol model in different
guises.
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.
The trouble is, I disagree - presence has a different model, because
privacy lists and directed presence lead to a distinction between
subscriber and receiver.
Generalized solutions are appealing, but there's always the danger
of
over-generalizing.
In general, one should never over-generalize.
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.
Indeed, and what we're talking about is just refining this a bit.
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.
I think we intercept, mimic, and fool the client into thinking it's
talking to the master service at all times.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
