A thought: disposable realtime notifications for webapps(blog.dustincurtis.com)
blog.dustincurtis.com
A thought: disposable realtime notifications for webapps
http://blog.dustincurtis.com/crazy-idea-create-a-link-from-webapps-to-grow
29 comments
Sounds like a good use for web hooks: http://webhooks.org/
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.
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 think competition here is pretty healthy. It's a new area, with lots of innovation.
The WebSocket in HTML5 looks pretty good, hopefully that'll be implemented soon.
The WebSocket in HTML5 looks pretty good, hopefully that'll be implemented soon.
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.
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.)
I made a Ruby script that does this with RSS/Atom feed polling. It's pretty cool to get notifications in growl this way.
Please please just use Java. It's open source and runs cross platform.
Then you can get all those valuable Windows / IE users and not just Mac 5%
---
From my previous post :: http://news.ycombinator.com/item?id=552633
* 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.
---
From my previous post :: http://news.ycombinator.com/item?id=552633
* 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.
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?
Netgrowl is a Python library: http://the.taoofmac.com/space/Projects/netgrowl
Here's an example I threw together: http://tlrobinson.net/blog/2008/09/01/adding-growl-notificat...
Here's an example I threw together: http://tlrobinson.net/blog/2008/09/01/adding-growl-notificat...
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.
I hacked together a Greasemonkey script + Python script that forwards Facebook feed notifications to Growl a few months ago.
http://tlrobinson.net/blog/2008/09/01/adding-growl-notificat...
It's rather cumbersome to setup though, and I haven't used it since the day I wrote it...
A nice centralized service that would connect users and web services would be great.
http://tlrobinson.net/blog/2008/09/01/adding-growl-notificat...
It's rather cumbersome to setup though, and I haven't used it since the day I wrote it...
A nice centralized service that would connect users and web services would be great.
1. Growl allows network connections, if you enable it. There are Windows and Linux clients that implement the protocol, too.
2. Scalable "Disposable realtime notifications" from server to clients/other servers was implemented over 20 years ago, with IRC.
Some green Web 2.0 guy thinks he has a great idea, is actually reinventing wheel, more news coming up at the top of the hour.
2. Scalable "Disposable realtime notifications" from server to clients/other servers was implemented over 20 years ago, with IRC.
Some green Web 2.0 guy thinks he has a great idea, is actually reinventing wheel, more news coming up at the top of the hour.
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.
http://imified.com enables web applications to be IM enabled
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.
Er, I meant "need to add another IM account to the IM application they are already using".
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.
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.
I use XMPP for this sort of thing.
My startup is using Juggernaut[1] for this purpose. The only drawback is it only supports flash-ed browsers.
And, it is not polling.
[1] http://juggernaut.rubyforge.org/
And, it is not polling.
[1] http://juggernaut.rubyforge.org/
Divvyshot has a system like this -- it's pretty cool!
Superb idea. Wish I'd had it.
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.