Dave Cridland wrote:
[...]
Sure, I think everyone here does. I sincerely hope so, anyway - we will
have significant impact here in the future.
We agree that messages should be sent only once per link?
[...]
You do, however, raise a very interesting point - you've said that in
the current MUC case, there's no gain in using repeaters.
There are situations where there is no gain:
* user joins
* muc service modifies repeater
* users leaves
* muc service modifies repeater
two repeater modifications for nothing. Separating the repeater
modification from the actual protocol steps is something I dislike
about repeaters.
[...]
The result of solving them would be that PubSub would almost
spontaneously grow directed acyclic routing, and this would be virtually
transparent to clients, and to a large degree, transparent to servers.
Note that this is more powerful than repeaters, as well as simpler.
As long as the local server (slave) rewrites the address to that of the
"master". Otherwise you have a usability problem ("but I want to join
[EMAIL PROTECTED], not [EMAIL PROTECTED]"). Make it transparent
to the client.
Again, we gain a lot from this. It's a simple design, and one that can
potentially get us some resilience to failure, which is nice. And again,
not my design, and not a particularly new suggestion.
IRC is there, you can't really come up with something brilliant new
that can't be interpreted as "irc does it almost the same" ;-)
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 ;-)
redistribution backwards, will yield equal or high efficiency, with much
simpler implementation, fewer security issues (in implementation or
design), and will give us all the benefits of a tree-based heirarchical
distribution without breaking any trust models.
You can apply the same master-slave design to presence.
The recipient list modification operations will be different for the
three use-cases, but the plan stays the same.
I don't think we'll have a problem scalaing presence, because I don't
think it really needs to be scaled - it's neither low-hanging fruit, nor
Buy two, get one free.
[...]
Not least of which is that, if this went ahead, we'd probably feel under
some obligation to use it in a MUC and/or PubSub scalability effort, and
I happen to think it's entirely the wrong design for that - there are
much cleaner designs.
I am going to curse you at night (in binary xmpp!) if I have to
reactivate our old master/slave rooms and map them to XMPP!
p
