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

Edward Artaud edward.artaud at gmail.com
Thu Sep 11 09:34:15 PDT 2008


It really depends on what the goals are.  First of all, mailman is
pub/sub in as much as there is distribution of mail to mailboxes, the
mail typically gets from the mailbox to your client through some sort
of poll mechanism.  My suggestion is the same, except that it's a
group mailbox (or feed) instead of individual mailboxes.  Secondly,
it's hard to argue that turning group chat into a feed system that
gets polled for updates, even using long polling with keep-alive, is
not going to be more fault-tolerant by virtue of it's simplicity than
the current system, which is pub/sub.  So, the tradeoff is more stable
versus lower latency.  IRC servers do go down and you can get
disconnected from a channel, a feed polling architecture doesn't fail
in that way, but yes, the latency issue is the question.  Of course,
with feed polling, you'd have other nice things, like potentially
being able to subscribe to a group chat via RSS with a feed reader,
and always having a recent group chat history if you joined a
conversation late.  Again, I'm coming at this from previous
experienced being involved in a consumer group chat project, and the
main complaints from users were that they found it unacceptable if
they could not join the group chat room when they wanted to, had any
sort of failure when trying to send a message, and getting kicked from
a group chat due to the server they were connected to failing and
missing chat history when they reconnected.  Most users did not have
an awareness of latency within the 5 second timeframe.  I do think
that IRC could be a viable option simply because of the maturity of
it, but if you're proposing building a new non-irc chat system based
on a pub/sub architecture and thinking that it's going to be more
reliable that the current group chat implementation in SL, then all
you're saying is you can do pub/sub better than the Lab, which I'm
going to take with a grain of salt.  For interoperability purposes,
not originating a new architecture unless it is more simple and
reliable than widely used open alternatives should be a key goal.

On Thu, Sep 11, 2008 at 7:41 AM, David M Chess <chess at us.ibm.com> wrote:
> Well, pub/sub requires that the system as a whole knows statefully who is
> subscribed.  The publisher doesn't necessarily have to know, and no single
> server has to know, just the system as a whole; pub/sub can be done in
> various cleverly distributed ways to reduce the requirements on any one
> server.  In my experience polling doesn't scale well unless there are
> relatively loose latency requirements (i.e. its okay if things sometimes
> take a long time to propogate), which I don't think we have in this case.
>  Pub/sub doesn't have to be heavyweight and hard to maintain; again, I think
> IRC is basically pub/sub, and IRC implementations aren't afaik famously hard
> to maintain.


More information about the SLDev mailing list