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

Harold Brown labrat.hb at gmail.com
Tue Sep 9 14:00:24 PDT 2008


I think what some people are forgetting in all these statistics and metrics
and whatever is that Large Groups in SL do not equal "Large number of people
in chat"

A group may only be used to send notices out to the members, others people
drop chat as soon as they get the first message and do not "join back in"
until they feel like chatting.

I have 25 groups, of those 25 groups only 5 of them EVER have chat occuring,
and of those 5 a very rarely keep all 5 going the entire time I am logged
in.


On Tue, Sep 9, 2008 at 12:41 PM, Edward Artaud <edward.artaud at gmail.com>wrote:

> There are a lot of tradeoffs of pub/sub vs polling, do a google seach
> on the words 'pub sub polling' and you'll see many pages on the
> subject.  True pub/sub (as opposed to RESTful pub/sub aka polling)
> means the server has to be statefully aware of who's subscribed.  In
> practice, not being statefully aware of your subscribers scales better
> than being aware of them, and as Poppy points out, nice things like
> caching and ETags/If-Modified-Since/304 Not Modified can be applied in
> an much more fault tolerant and inexpensive brute force way rather
> than true pub/sub which typically requires a lot more complex (and
> harder to maintain systems) to operate at scale.  As to the user
> experience, there's no reason why any of the approaches discussed
> would have to chage the existing user experience.  My point is that
> something I learned while implementing just such a system several
> years ago was that group IM with no constraint on number of
> participants is a totally different beast than 1 to 1 IM.
>
>
> On Mon, Sep 8, 2008 at 4:25 PM, Paul Oppenheim (Poppy Linden)
> <poppy at lindenlab.com> wrote:
> > David M Chess wrote:
> >>
> >> I don't really understand this scaling argument.  In my experience,
> >> neither "push everything everywhere" nor "constantly ask if there's
> anything
> >> new" scales; what scales is actual pub/sub.  In the case of group IM,
> >> messages get pushed by some server (or some cluster of entities acting
> as a
> >> logical server) to all and only those places where someone cares.
>  There's
> >> some overhead in keeping track of where there are places that someone
> cares,
> >> but in most use-cases I've seen it's the approach that scales the best.
> >
> > Do you have any references / links / copypasta / personal stories on this
> > kind of architecture research? I've been hungering for scalability
> research
> > lately, and been surprised by much of what I've read. I would assume
> polling
> > with caching would be much faster than pub/sub because you can use much
> > dumber machinery, but I've also not investigated too many message queuing
> > systems (I also don't work directly on IM). I can't speak for others on
> this
> > list, but if you cook up a scalability resource mail you've got an
> audience
> > of at least one ;)
> >
> > + poppy
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting
> > privileges
> >
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/1432b629/attachment-0001.htm


More information about the SLDev mailing list