[jdev] resources available via XMPP...

[Jeff McAdams]

Ernest Nova wrote:
> --- Jeff McAdams <jeffm at iglou.com> wrote:
>> Regardless, though...one of XMPP's real strengths is that its more of
>> an
>> event-driven system...but so many people just don't grok the power of
>> that, and some real, useful, demonstrations of what's possible would
>> be
>> very powerful to have available...but if you just dump an RSS feed
>> into
>> a bot...I might as well just poll the RSS feed from my aggregator
>> myself, the XMPP capability is wasted.  (There is, of course,
>> reasonable
>> uses for having an RSS or ATOM feed via XMPP...but the real-time
>> capabilities of XMPP are what I'm trying to highlight, here)

> No debate about the event-oriented real-time nature of XMPP ( vs RSS) -
> but I believe notification is only part of the story.  The compelling
> part of XMPP (or IM in general) is not just that you can notify in
> real-time - but after the notification is delivered - the information
> has already been presented in a format/forum where it can be natively
> collaborated upon (i.e chat rooms). This would not be possible with a
> feed reader where you would have to switch apps etc.

Honestly, despite my involvement with iemchat, where we do exactly this,
I don't think having the notification in the collaborative forum (ie,
chatroom in this case) is all that important.  It *is* nice, that it is
in the chatroom, but I believe the timeliness of the notifications is
much more important.

Many of the people that come to the public iemchat chatrooms come, not
to chat with other people (many of the rooms don't have more than one
person in them as of yet), but for the timeliness of the notification of
the events.  (iembot is the fastest way to get notifications of NWS
alerts...it regularly beats our NOAA Weather Radios by 30-45 seconds).

That some of the chatrooms do then foster collaborative discussion and
monitoring of those events is awesome...but I'm regularly seeing people
leaving a window open in the chatrooms even when noone else is in there.

The comments from people about IEMChat (both the public and private
versions) are more frequently about the speed of iembot posting the
messages than that they are conveniently in the chatroom where other
discussion happens.  Both aspects of the system draw positive comments
from people, but the timeliness seems to be more frequently the major
feature that people like.


Also...this only works this way to a certain point.  Chatrooms don't
scale for handling notifications of events.  As you start to get lots of
different types of notifications being sent, the chatroom starts to get
really cluttered (we're not there yet, but if many notification types
get sent to chatrooms, it won't take long).  So, yeah, while chatrooms
are a good first cut at solving the problem, I firmly believe that the
ultimate solution, here, is some sort of client app that is *like* an
RSS aggregator, but uses XMPP pubsub as the transport (because of the
real-time capabilities).  Perhaps those events will include a link or
button or something like that which will get someone into a relevant MUC
room.  *shrug*  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.  (I looked at the
superalert thing that was just posted about...that sort of thing is kind
of what I was thinking of).  Using something like pubsub allows the user
to filter the notifications they receive effectively, while not being
overwhelmed by having (necessarily) to have many windows open for each
different type of notification.  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.  (Yeah, ok, MUC can be thought of as a poor man's pubsub, and
mediated by a client that joins specific chatrooms in the background for
you, but if you're going to do a pubsub'ish thing, why not just use pubsub?)

> I believe post-event collaboration is just as integral a part of
> first-response, even if the initial notification was slow

To some degree, it depends on the nature of the event.  Even within the
overall area of weather, the timeliness needs of different types of
events vary.  Flood warnings?  Important, but a 15-minute lag probably
isn't going to cause any serious problems.  *Flash* flood warnings?  15
minutes could be a killer (literally).  Tornado warning?  15 minutes and
there's a good change that its all over already.

Yes, the polling intervals can be shortened, but I think we all
understand how problematic that "solution" becomes long-term.


And, yes, in first-response situations, collaboration is important, and
yes it probably is more convenient if relevant events are posted in the
collaborative forum automatically for the users.  Ultimately, I think
the main notification engine needs to be a pubsub'ish thing.  For
collaborative environments that want to include the events in messages
to the collaborative forum, you have a bot that receives the
notifications off of pubsub and posts them like iembot does now.  That
allows for much greater control of how notifications of events are
routed and handled than using MUC as the primary communications channel.
 It also allows for multiple forums to easily have overlapping but not
congruent sets of notifications to be sent to different places.  That's
not quite so easy to do using a MUC setup, unless you use it as a poor
man's pubsub as I mentioned earlier.

> ( I believe this is how you started the thread ;-) )

I really have tried to avoid any emphasis on chatrooms and collaboration
in this thread and focus on the notification aspects (and reading the
archives, I think I mostly have).  The collaborative stuff is cool, but
as a problem is largely solved (XMPP IM and MUC works pretty well).
Real-time notification systems on the Internet largely suck.  They tend
to be very domain-specific, and difficult to integrate and use.  XMPP
offers very compelling technology to help solve those other problems.
To do so in a way that works well with group collaboration would be
fantastic, but just throwing everything in a chatroom isn't a great
solution long-term.  (You can ask Daryl, that guy that started IEMChat
and mainly runs it, I've suggested to him multiple times that using CAP
and pubsub would be a good thing).  Chatrooms are a good starting point,
but I don't think they offer a long-term solution to this sort of
problem space.



Good discussion, thus far, though.  Thanks!  :)
-- 
Jeff McAdams
"They that can give up essential liberty to obtain a
little temporary safety deserve neither liberty nor safety."
                                       -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <https://www.jabber.org/jdev/attachments/20080421/9d506a10/attachment-0002.pgp>