[Standards-JIG] JEP-0045: 1.21pre6

[Boyd Fletcher]

On 8/24/06 3:16 AM, "Matt Tucker" <matt at jivesoftware.com> wrote:

> Justin, 
> 

deleted...

>  
>>> 2) allows for redundancy in MUC architecture without resorting to
>>> proprietary tricks on the end
>> 
>> Clustering is often specific to a given server
>> implementation, and in that case "proprietary" options are
>> quite acceptable.  Now, if you want to make a case for an
>> open XMPP clustering protocol, that could be interesting.
>> However, I don't think it would have to be specific to MUC.
> 
> Generic clustering doesn't really apply to what Boyd is suggesting. It's
> not clustering of a single domain, but doing MUC replication and
> optimizations between multiple different domains.
> 


correct

>> By 'many folks', you mean people on ships, right?  I don't
>> think the lack of MUC relaying is holding any 'normal' user
>> back.  Your use-case might be enough to justify a specialized
>> protocol, but only if it can't be solved by a typical XMPP cluster.
> 
> I've heard the intermittent network scenario (like on ships) several
> times as a justification for a MUC relay feature. However, I've also
> heard it requested by people trying to scale MUC to very large numbers
> of users. Splitting a large user base into multiple domains and then
> using s2s is typically a lot easier/cheaper than trying to setup
> clustering for a single domain.
> 
> Also, a funny thing about the existing XMPP clustering implementations
> -- I'm virtually positive that nobody has actually done clustering of
> MUC yet. :) Also, I'd guess that clustering on an intermittent network
> would be much harder than doing MUC relay between different domains
> (where each ship is a different domain).
>  

we are also see the need with using MUC relaying when trying to have chat
sessions with people in countries or places with less developed
infrastructure. For example, we use XMPP for coordination between people
doing humanitarian assistance/disaster recover operations. These types of
people are frequently using SATCOM or Cell Phone connectivity. Which both
have a tendency to be high latency, low bandwidth, bursty, and not reliable.
With MUC relaying users at each site can continue to collaboration
internally and/or with a subset of users without being kicked out of chat
room or forced to create another chat room. This lack of MUC relaying is one
of the major reasons IRC is still popular today.


>> It could work.  But I also think an XMPP MUC cluster with a
>> "proprietary" 
>> inter-server protocol would work too.  Your situation might
>> be specialized enough not to bother with JSF approval.
> 
> You could be right, although I think optimizing MUC traffic between
> different domains is an interesting case that could be broadly useful.
> It's sort of like JEP-33, but for MUC.
> 
> Regards,
> -Matt