[sldev] Question: Replacing current group chat with XMPP?

[Lawson English]

Edward Artaud wrote:
> Having built these types of group chat systems in the past, at a
> certain point, they tend to move to a pull model of polling a chat
> history rather than the push message propagation model, so that the
> client can basically ask the server to deliver to it the new chat
> events posted since the last poll time.  After all, there's a reason
> why there's a limit to the number of agents you can have in a single
> region, the problem with groups is that they often have an order of
> magnitude more members.
>
> On Sun, Sep 7, 2008 at 2:01 PM, Christian Scholz / Tao Takashi (SL)
> <tao.takashi at googlemail.com> wrote:
>   
>> I also wonder if the group situation will stay that way on the long
>> run with OGP. Right now with only 25 groups you probably need to stay
>> in the big groups to stay connected. If you wouldn't have that
>> requirment and the whole world is more decentralized anyway I wonder
>> if those groups would look different. Additionally if you are more
>> free to join and leave without any hassle (like you might do with IRC
>> channels). Right now with that limit you always have to think plus I
>> think some groups have member restrictions because of the lag (IIRC).
>>
>>     

Once pyogp gets to a certain level of maturity, we can start testing 
massive numbers of accounts for scalability purposes for things like 
group IM. As it stands now, I think it is obvious that we need to 
support *at least* the current setup for SL groups within the SL Agent 
Domain (either that or suddenly change how everyone in the World 
communicates with each other when the Agent Domain comes online in agni).



My conception for the current group IM as it could be done in OGP, is 
simply to make the Agent Domain responsible for forwarding group 
messages to individual avies. The IM server tracks membership AND the 
associated Agent Domain and sends the Agent domain a message for each 
group with recipients attached (or the AD could request such a list). 
The AD is responsible for determining if a given recipient is online or 
not, and forwarding the message to the client or to email or just eating 
it. Responses to the group IM server are sent directly to the server or 
they could be collected and forwarded in some way.

The idea being that the busywork of keeping track of who just logged on 
or off is now put on the AD and not the group IM server.

Other forms of IM, might go directly to the client via plugins, 
bypassing the AD completely, or, in the case of ad hoc sessions, an 
encrypted CAP could be sent from a corporate grid via normal 
communications through the AD, and decrypted using a key given to the 
client out-of-band (corporate email) and a direct session of some kind 
could be set up without the participation of the AD.

In any case, arbitrarily deciding to forgo the current SL group IM 
design is not really an option, as far as I am concerned. The SL 
community is set up aground the current chat behavior (missing messages 
and errors aside), and to suddenly change that would be more than a 
little disruptive. No need to limit ourselves to just the SL model, but 
to just chuck it out is a big no-no.


Lawson