Pusher - Realtime client push service powered by websockets(pusherapp.com)
pusherapp.com
Pusher - Realtime client push service powered by websockets
http://pusherapp.com
8 comments
This is really awesome; except as an app developer, I really rather get a library that I own and have on my own infrastructure than a SaaS model, especially for something so critical to my application.
If you just want the raw "back end WebSocket-compatible multiplexing daemon" functionality, that's not hard to code/devise. You can use something like: http://github.com/gimite/web-socket-ruby - What services like Pusher provide is all the API stuff on the front, maintaining the servers, keeping those daemons running, and, well, just making it super easy to get going without worrying about the back end so much.
All the API stuff on the front I'd pay for. However, I'm already paying for "maintaining servers, keeping them running, and worrying about the backend" -- so I don't want to pay for it again.
This might just be MY preference, and others might beg to differ.
This might just be MY preference, and others might beg to differ.
It depends on the type of app you're building. We built Pusher to complement existing AJAX workflows and make adding collaboration easy. There's lots more you can do with it though.
I'm thinking about giving this a try: http://github.com/slact/nginx_http_push_module
Luke Redpath has also published an interesting post: Pushing events to your iPhone using WebSockets and Pusher
http://lukeredpath.co.uk/blog/pushing-events-to-your-iphone-...
I've been using notifo to notify myself of the completion long-running computing tasks.
Growl could probably do the same thing, but I already have notifo working and I'm a cheapskate. (Plus, IIRC if I want to use Prowl I need to have Growl running on a PC somewhere).
Growl could probably do the same thing, but I already have notifo working and I'm a cheapskate. (Plus, IIRC if I want to use Prowl I need to have Growl running on a PC somewhere).
Try Socket.IO: http://labs.rosepad.com/socket.io/
Also, Socket.IO fallbacks to flash and other non-socket methods (htmlfile, xhr polling, xhr multipart, more to come), while conserving a WebSocket-like API. And you can implement any protocol you want on top of it (such as STOMP, Bayeux, XMPP).
It's usually writing a good server that is the pain point here.
http://github.com/Rosepad/Socket.IO-node/ powered by Node.JS, check out the basic chat app in 10 LoC
Oh, fun :) I'm just about to launch a similar service, called Zeropoll. It seems you're pushing the event-handling logic to the client side, whereas Zeropoll generates Javascript on the server (ala RJS) and pushes that to the client.
Your demo apps are great, by the way. Just curious, what's your business model going to be?
Your demo apps are great, by the way. Just curious, what's your business model going to be?
When we're out of beta we will be offering several plans, probably limiting the max clients. There will always be a free plan though :)
This is great, I was thinking about making a similar app, but never got around to it.
I'd love a simple ACL for channels. For example, you could do S3-style channel+timestamp+hash authentication, with the hash generated on the server with a secret key. Then for every channel I'd have channel17@r for read-only access, channel17@w for write-only, and channel17 for rw access (default). The way I understand the current system once I have the key for a channel I have unlimited access to it forever.
I'd love a simple ACL for channels. For example, you could do S3-style channel+timestamp+hash authentication, with the hash generated on the server with a secret key. Then for every channel I'd have channel17@r for read-only access, channel17@w for write-only, and channel17 for rw access (default). The way I understand the current system once I have the key for a channel I have unlimited access to it forever.
I am working on something exactly like this, but as an open-source NodeJS project.. it lets you define a parameter (by default, session_id) and then checks a memcache instance for that key, and uses that to get access to channels with a specific prefix (by default "user:")... so you can have a channel "user:34343". This shoves authentication back into your app with the only dependency being a memcache instance shared by the NodeJS server and the web server. All of the other communication is similarly RESTful. if you want an email when i've got more to show, let me know.
Glad you think it's cool, we are pretty excited.
Authentication and access control are features which are very important, and we are working on a couple of options for doing it. Something similar to what you have described is the current favourite, though the hashing probably won't be passed through at channel level.
We decided to get the Pusher launched into beta with stuff like this left out so that we could get a gauge for people's general enthusiasm for such a service.
We'll be busy in the next couple of weeks reacting to feedback, so it is great to have these kind of comments :)
Authentication and access control are features which are very important, and we are working on a couple of options for doing it. Something similar to what you have described is the current favourite, though the hashing probably won't be passed through at channel level.
We decided to get the Pusher launched into beta with stuff like this left out so that we could get a gauge for people's general enthusiasm for such a service.
We'll be busy in the next couple of weeks reacting to feedback, so it is great to have these kind of comments :)
This sounds very interesting, but since it is a SaaS model and you are relying on their infrastructure, what exactly are they looking at as their business model? Freemium? Any idea of pricing?
It is something I could use in an app I'm working on right now, but I'm just building a simple free tool and would be interested what their plan is for the service before I get myself tied to it.
It is something I could use in an app I'm working on right now, but I'm just building a simple free tool and would be interested what their plan is for the service before I get myself tied to it.
Looking good! One question: As I was checking out the "theater booking" demo, I opened two windows, and in one window I checked out 2 seats. It required an actual refresh on the other window to show the updated seating chart; however, on the other app I tried (to-do list), that was not necessary.
Was this done on purpose?
Was this done on purpose?
Sounds like a bit of a bug.
There may be minor glitches in the demo apps. They haven't been where we've been focussing the majority of our energy :)
There may be minor glitches in the demo apps. They haven't been where we've been focussing the majority of our energy :)
Great! Exactly what I need to supplement Google App Engine.