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.
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.
We tried nginx http_push_module before building pusher, and it was definitely one of the inspirations. I'd recommend it if you want to use long polling and are happy to maintain your own infrastructure.
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).
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).
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?
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 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.
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.
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.