I'm mostly curious about this because we're working on getting something similar into our API right now (the subscribe part, scripting has been there for awhile now) and I've been thinking a lot about this stuff recently, I've probably been pushing the most out of anyone here.
Did you guys have a reason for going for chunked over long polling though?
1. Client makes a request, somehow indicating that it wants to do long polling (url, header, etc.).
2. Server receives the request, but does not reply, the socket is left open.
3. An event occurs, then the server finally responds to the initial request with information about the event.
4. Go to 1.
So it's basically polling, except the server just seems to take a really long time to respond.
In the end, both ways are completely valid methods, I was just wondering if there was any particular thing that swayed you either way.
To answer your questions about the alert code, yes it runs in a sandbox, but we also parse it and take it through a pretty lengthy pre-check process to weed out any code that might cause performance bottlenecks or general security problems.
As for websockets, we actually do support them (well, technically socket.io) but just don't make it very clear in the documentation. If you take a look at our open-source javascript client (https://github.com/buglabs/dweetio-client/blob/master/dweet....) you can see that we're actually using it there.
Hope that helps.