It's a great idea (well, a great extension of Growl's concept), but the infrastructure isn't there — not entirely.
For real-time notifications to happen (and be reasonably lightweight), you need to have hooks into your monitored services. Growl works because its clients send messages to the Growl server on your machine when something interesting happens.
Web services will need to have a similar mechanism for (securely) telling your notification service that "something happened." Weblogs are already most of the way there: modern blogging engines can send HTTP "pings" when new entries are posted. Apache sends its errors to a file, so it would need to be extended to post errors to your notification service.
I'm rambling now, but if anyone wants to start a working group or somethin', props. It's going to need some intelligent design to take the weight of the whole internet flowing through it and to ensure that private notifications (your web server, Facebook) don't get into the wrong hands.
This would essentially be Push RSS; you could accomplish the same thing via RSS but with polling. A push-based solution would be much cooler though, and would make more sense for notifications or events.
Yes, but that's the easy part, isn't it. Anyone can write a quick polling app based on RSS.
The hard part is (off the top of my head ...):
o Putting together a UI that people can use and will like. Notifications should be quick and easy to set up. They should be noticeable enough to work, but they should not cause problems with existing workflows. And the whole system needs to be easy for the user to understand.
o If a new protocol: get sites all over to use it. If an existing one, figure out how to wrap around it nicely (extract and display the right info, etc.).
o Integrate this with non-RSS stuff, like the things that Growl does.
Brad Fitzpatrick's http://code.google.com/p/pubsubhubbub/ can be used for this. ("Subscribe" to a RSS/Atom feed, it does the polling for you, and gives you callbacks when new entries happen.)
In a similar vein, I'm noticing more and more social sites implement their own site-specific chat frameworks, as well as notifications (I'm looking at you facebook and gmail).
We went through this once with icq/aim/msn, and it would be nice if browser vendors got together and worked out something that unified 'push' messaging before everyone implemented it separately.
I thought about doing this, but Growl running on one system (e.g. desktop) can accept notifications generated by a different system (e.g. server), but unfortunately the client library is Cocoa only, so you can't compile it on your Linux host, etc. (I think this is all correct.) Has anyone "fixed" this?
* Desktop Notifications - This is solved, I wrote one myself[1]
Try using existing Java/Browser technology.
I would suggest this:
Each compatible web page has a signed applet which can also run resident on the remote machine via Webstart. If the server is not listening yet, start it.
If it is listening, send it a message. The Webstart remote applet then displays the message in the GUI.
My server just bound to a range of well known sockets, and the clients tried each one in turn. Try to keep it simple. I just wrote a string with a carriage return to the socket. No XML, no heaviweight protocol.
Adobe is working on something like this. It's growl for web apps. Basically, your web service pushes notifications to this app. It's exactly what you're talking about. Once I dig more info up, I'll try to post it here.
Really interesting project I came across the other day. Juggernaut (http://juggernaut.rubyforge.org/) esentially a lightweight push server. I am using it for a simple realtime web-chat client. Although you can use it for for notifications. This would be sweet.
That's a bad idea, because you end up piggybacking on top of another service, unless you do something like.. individual users run their own jabber servers.
Or you could provide a jabber server that uses your web app's authentication mechanism so users just need to add another IM account to the IM account they are already using. Or things like growl could take an jabber server as a configuration option to receive notifications from. Desktop notification is mainly just a reformatting of the UI on technologies that already exist, are in use, and are pervasive.
You could also run a laconi.ca microblogging server, here's a list: http://laconi.ca/trac/wiki/ListOfServers and any event is sent out from one account from which all users are subscribed.
There are three platforms that are doing this totally differently: Apple, Palm, and Google. They're doing it in the mobile space, but if one of them "wins" (ie, the others start supporting their push API), I can see the browser vendors picking up on it too.
I don't see why twitter isn't appropriate for this.
The reason given is that "Twitter facilitates user <=> user communication". But he gives no explanation for why Twitter couldn't also be used for the sorts of communication he discusses.
Just because twitter CAN do it does not mean it's the most appropriate. For one the character limit kind of kills it if you want to send a really long CallBackURL.
Twitter stores all of the messages and gives the impression of being a queue that you should read. Imagine if you inserted your facebook feed into your twitter stream. It would be so much useless junk, that you'd be unable to actually communicate with users on Twitter.
For real-time notifications to happen (and be reasonably lightweight), you need to have hooks into your monitored services. Growl works because its clients send messages to the Growl server on your machine when something interesting happens.
Web services will need to have a similar mechanism for (securely) telling your notification service that "something happened." Weblogs are already most of the way there: modern blogging engines can send HTTP "pings" when new entries are posted. Apache sends its errors to a file, so it would need to be extended to post errors to your notification service.
I'm rambling now, but if anyone wants to start a working group or somethin', props. It's going to need some intelligent design to take the weight of the whole internet flowing through it and to ensure that private notifications (your web server, Facebook) don't get into the wrong hands.