But it seems that Dweet.io adds subscriptions and alerts to the mix - actively pushing data out to subscribers or when certain conditions are met. That's a nice addition.
Full Disclosure: I work for a competitor of theirs as an embedded engineer.
Question for any bug labs people. How are you guys running the alert code? I assume it's something long the lines of a node sandbox that just runs the bit of JS, I've only looked into that stuff breifly. I was also looking at using really light weight interpreter called Duktape for a personal project. It has got a really similar C interface to Lua, but that ended up being way too much work and I abandoned it. I also recently found an erlang js interpreter that looked really interesting too, can't remember what it was called but it was from one of the erlang nosql databases, they used it for doing map reduce.
Also, why did you guys decide to go with chunking for the push over something like long polling or websockets? I assume the websockets was because of device code complexity, but longpolling seems more standard/less of a hack to me.
I always love seeing how others implement these kinds of things.
Hey azdle, thanks for the question and being honest. Do you mind me asking who you work for? Just curious more than anything.
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.
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?
Not exactly sure what you mean by long-polling in this context. Do you mean a client making calls to the API at regular timed intervals to check the status? Or do you mean the server making calls to an endpoint URI when an event occurs?
13 comments
[ 3.1 ms ] story [ 43.0 ms ] threadHere is a direct link: http://beta.dweet.io
http://buglabs.tumblr.com/post/94633748906/dweet-tm-now-with...
But it seems that Dweet.io adds subscriptions and alerts to the mix - actively pushing data out to subscribers or when certain conditions are met. That's a nice addition.
Question for any bug labs people. How are you guys running the alert code? I assume it's something long the lines of a node sandbox that just runs the bit of JS, I've only looked into that stuff breifly. I was also looking at using really light weight interpreter called Duktape for a personal project. It has got a really similar C interface to Lua, but that ended up being way too much work and I abandoned it. I also recently found an erlang js interpreter that looked really interesting too, can't remember what it was called but it was from one of the erlang nosql databases, they used it for doing map reduce.
Also, why did you guys decide to go with chunking for the push over something like long polling or websockets? I assume the websockets was because of device code complexity, but longpolling seems more standard/less of a hack to me.
I always love seeing how others implement these kinds of things.
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.
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]http://exosite.com
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.