On Thu Feb 18 13:44:02 2010, Philipp Hancke wrote:
Kevin Smith wrote:
[...]
8) Distributed MUC
http://xmpp.org/extensions/inbox/distributedmuc.html
Accept as XEP?
Kev offers to send around a mail about an alternative approach to
possibly update this proposal with.
Kev, Matt and Ralph had no objections to publishing as-is, further
discussion about approaches to happen on-list.
1. This proposal has unacceptable liabilites (sync issues).
See
http://logs.jabber.org/coun...@conference.jabber.org/2006-06-14.html
at 15:28
2. Compression makes multicast structures unnecessary.
Jack may remember the argumentation... 15:28:19 in the same meeting
log.
3. This proposal does not disprove current experience
- 15:30:12 in the meeting log.
4. This indeed is the worst of IRC brought to XMPP.
Ah, gotcha, you're referring to smart presence distribution, and
ironically comparing the reaction of the council. How witty.
1) Without trundling back to the threads to remind myself what the
sync liabilities are, I suspect this refers to assymetric rosters,
which have remained a problem (and the current resolution is to
respond to probes on a case-by-case basis to re-symmetrize - if
that's a word - the rosters, which'd entirely break with "smart"
presence distribution). Distributed MUC is specifically designed (one
hopes) to handle synchronization of relevant state data, and is
allowed (specifically) to do all manner of weird things to mitigate
the liabilities therein.
2) S2S compression remains our best solution to the matter of
inter-domain presence bandwidth, but I'd note we have nothing like
the issue that other protocols have. I do have some research I need
to carry out on this, but I currently lack the time. In any case,
I've read this proposal as an attempt to tackle resilience rather
than efficiency as the primary goal, so I'm not convinced this
argument is worth revisiting for this proposal - but the distinction
of trust delegations means different solutions may apply.
3) I'm not sure exactly what Matt Miller intended to mean at this
point, but I suspect it relates to Peter's suggestion to get hard
data. See above - on the subject of inter-domain presence (and, for
that matter, inter-domain MUC traffic), I'm intending doing some
measurements when I can on actual field data, although my
measurements based on more theoretical cases seemed to hold up, and
the observation that the bulk of bandwidth consumption is highly
self-similar, and thus should compress well, is still valid.
4) I understand this proposal is aimed at bringing simple resilience
for chatrooms across heterogeneous XMPP networks, very much like IRC.
I'd be interested in seeing how you'd do it. I do think you're much
better placed to find a reasonable solution, and in this case, where
trust relationships are explicitly configured, I'd expect the kinds
of solutions you're likely to propose to be more acceptable to us
annoying folk in the XMPP world.
Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
