[jdev] resources available via XMPP... [long]
ennova2005-jabber at yahoo.com
Mon Apr 21 20:55:10 CDT 2008
Let's see if I can summarize for my purposes :) Longish response
--- Jeff McAdams <jeffm at iglou.com> wrote:
> I don't think having the notification in the collaborative forum (ie,
> chatroom in this case) is all that important.
> Also...this only works this way to a certain point. Chatrooms don't
> scale for handling notifications of events.
> The collaborative stuff is cool, and an obvious
> outgrowth of the use of IM as an app, but I think there is a huge use
> case for just using XMPP technologies as a real-time notification
> system, even without any chatroom/collaboration
> Real-time notification systems on the Internet largely suck.
> With chatrooms, you either have all
> notifications in a single chatroom and risk getting overwhelmed by
> or you have a separate chatroom for each type and have to deal with
OK - I am in violent agreement with your ultimate choice, but not
entirely satisfied by your reasons :-)
Given the nature of your application category (a variant of
public-safety/ first-response), I suppose my reaction is one of:
"But, but .. you are not even using *all* the good parts".
That said, take from XMPP what you like :-) Back to this later.
You say, in your experience, speed of notification has been more
important than subsequent collaboration in first-response. I was
arguing that they may be equally important and use of XMPP or any
presence-enabled IM service SHINES most when an application can weave
in both aspects: low-latency delivery and built-in collaboration;
first-response being one of those situations.
Like all things in life that comment about first-response is an "it
depends" item. "Information" in the face of an imminent or ongoing
public safety event is both "system-generated" and "user-generated".
For example, having had a house in the line of the California fires
last year, a time-sequenced flow of information from applications
immediately validated by first-person accounts, such as is presented
naturally ordered in a chat room, possibly moderated and geo-location
tagged, would have been of most help rather than asynchronous
[Obligatory reference to handling of Katrina suppressed]
Likewise, a "run for your lives" event requires prompt notification and
initially probably not much else but I would argue that you are not
always going to be sitting around in front of a computer ( for
computer, read richly-connected device). The need would be to deliver
the alert [and subsequent updates] to personal mobile devices in
parallel and an IM application may not always be the fastest
notification delivery mechanism on mobiles. It is still the the best
app when you need people to people communication following
In other words, notification is just the start of the process in these
situations. "So now I know what has happened, what do I do next? Who
else can help? What else do they know ? How about now ? etc.
I am not claiming that notification+collaboration is required in all
cases. By way of background - we have in fact built several
minimalistic notification and ack-capture only IM clients for financial
services and logistics companies and do agree that the predominantly
always-on long-lived tcp-socket connection nature of IM client/server
implementations makes them the fastest delivery system (when compared
to "push-email" and "pull-web").
However, even in many of situations above the use cases ultimately
extended to "collaboration following notification" so an IM-based
platform made the best sense to start off with.
I should note that when building for pure notification use cases, we
ended up building alert delivery via direct one-to-one IM , that is
direct messages from the bot to each end user, rather than via chat
rooms. This was mostly because, as you have also alluded to, chat room
implementations have not yet been designed to scale for broadcast
functions. In large populations, they can also keel over just with the
normal join/leave traffic even when no messages are being posted to the
rooms. Also, not every end-point will be on XMPP chat rooms or even
pub-sub and other delivery mechanisms (SMS, voice notifications) are
easier to support with one-to-one messaging.
IM servers do act as fast message switches - so we found replicating
messages "outside" the IM server and then pumping them through the IM
system resulted in the fastest delivery (as compared to using the
replication capability of the chat room. We also side-stepped the
group presence-traffic this way.
Where chat rooms were a requirement because notification needed to be
followed by group discussion/ situation analysis and then decision, we
had to build sophisticated filters and audio/video cues on the IM
clients to manage analyst "Attention" appropriately.
It might offend some, but pub-sub is at high functional level
essentially an access-controlled broadcast chatroom without the
presence traffic/ room roster. The message replication performance and
scalability there too will depend on the implementation. You do get the
benefit of light weight topic/subscription management - but in any
sophisticated alerting system with complex subscription rules, these
rules would need to be populated outside the IM-system using a more
visual interface. You may also lose the benefit of presence-based
dynamic routing of alerts.
If you are still reading, by now you may already have started to
recognize a nod to John Kerry - I am about to argue against the idea
after I have argued for it
I agree that large-scale notification systems on the internet, as you
say, "suck" - but as an IM-biased-developer the next part is going to
pain me even more to say.. If all you *really* want is super-fast
internet scale notification, and the collaborative part is, as you say,
a "shrug"; Then, mister, I would argue then that XMPP, even with
pub/sub, is in fact heavyweight for notifications. XMPP is not a
lightweight protocol (comparisons to SIP not withstanding) and one
could build better optimized and scalable systems for first-response
You may for example be better served by a stripped down tcp-socket or
other ordered-delivery server that does little else but initial
authentication and leaves the pipe open for pushing further data down
to the client. The client could then be integrated with our non-IM apps
such as an RSS aggregator or an embedded browser component to collect
related information. Even certain readily available JMS systems, by
definition pub/sub servers, have much higher message switching
throughput and lower latency, and certain web-streaming technologies
can accomplish higher speeds and number of simultaneous connections
over web browsers (search for the financial tick data delivery)
Coming back around now ...
That said, no matter how you came to pick XMPP for public safety
notifications given faster alternatives, over time you will appreciate
your choice even more for *all* that it offers. I believe most urgent
notification will need to be followed by a multi-channel collaboration
or a closed-loop response.
More information about the JDev