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

[Edward Artaud]

Yes, that's why I why I addressed both in my previous email.  The
point is that single web servers (even with dynamic pages) routinely
serve well over 20 requests a second (which I think was your estimate
of # of requests for polling), and http already has ways to further
optimized with etags and such, and more importantly, can be
administered and scaled by a much less experienced ops team than a
pub/sub system, whereas your approach will require the Lab to recruit
very expensive MQ people out of IBM Global Services or Tibco to keep
it reliably running 24/7.  Most companies just don't have the
resources and expertise to run large scale pub/sub systems.

On Wed, Sep 10, 2008 at 9:24 AM, David M Chess <chess at us.ibm.com> wrote:
> I've probably been unclear here about what I mean by "pub/sub".  In
> particular, subscribers to an RSS feed are *not* in fact subscribers in this
> sense; they are in fact polling, which is exactly what I want to avoid for
> scalability reasons.  On the other hand, IRC basically is a pub/sub model:
> within the overlay network formed by the IRC servers, certain users
> (clients) subscribe to certain channels, and when a user talks ("publishes")
> on the channel, the message is sent (push-style) to all and only those
> servers that currently have a subscribed client.
>
> For me (and I think traditionally in comp sci before RSS terminology came
> along and muddied it up), pub/sub (publish/subscribe) refers to a system
> where there are topics or channels or subjects or whatever, some set of
> entities subscribe to one or more channels, and then some set of entities
> publishes one or more objects into one or more channels, and each subscriber
> is sent (rather than polling for) whatever objects are published into the
> channel(s) that that subscriber subscribes to.  So the publisher does not
> (necessarily) know the list of entities that will get the message, and the
> subscribers do not (necessarily) know who the publishers will be; instead
> the association is via channels, and the pub/sub infrastructure takes care
> of it without the publishers or the subscribers having to do the accounting.
>
> Something like that anyway.  :)
>
> Dale Innis
> DaleInnisEmail at gmail.com
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>