[Standards] Fwd: Meeting minutes 2010-02-15

Dave Cridland dave at cridland.net
Thu Feb 18 14:31:59 UTC 2010

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/council@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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list