Let's see if I can summarize for my purposes :) Longish response follows excerpt.
--- Jeff McAdams <[EMAIL PROTECTED]> wrote: [arbitrarily edited] > 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 > the > notifications in a single chatroom and risk getting overwhelmed by > them, > or you have a separate chatroom for each type and have to deal with > that. 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 notifications. [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 notification. 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 one-way notifications. 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. ~E.
