Websockets Agent

[snicker]

Consider this a suggestion for a websockets agent. Potential use includes any application that is using websockets for pushing data to the client. http://theforklift.net comes to mind.

[0xdevalias]

Added to agent suggestions list in #353

[Mask]

I though I would take a stab at this - here's my general idea:

1. A websocket_gateway daemon would be launched by foreman (similar to TwitterStream) and be responsible to managing persistent websocket connections. It would periodically (say, every 60secs) scan the DB for active WebSocketAgents and create websocket connections for these agents. It would react to websocket events (open, close, message) by sending normal http POST webrequests to huginn.
2. WebSocketAgent implements receive_web_request and emits huginn events with create_event.
3. Additionally, the websocket_gateway could have a http-server to enable WebSocketAgents to POST messages whenever an agent receives an event. These messages will then be sent over the websocket connection by the websocket_gateway.
4. A WebSocketAgent could also query the status of the connection via HTTP GET, and return this in its working? method.

In a nutshell, the websocket_gateway translates websocket events to discrete HTTP requests.

I have 1 & 2 working so far and it feels quite good. For 3 & 4 an additional dependency em-http-server would be needed.

@cantino Do you find this agreeable? If so, I would continue with this, clean up the code a bit, write some specs & start a PR.

[cantino]

Hey @Mask, that's a cool idea! I think it makes a lot of sense to run a daemon with foreman, much like twitter_stream. Also similar to twitter_stream, you could use the database as your bus instead of posting HTTP requests back to Huginn. Could you instead call a method on the listening WebSocketAgent that enqueues Events that Huginn will handle via delayed_job? What do you gain from the internal HTTP requests?

[Mask]

I'm trying to avoid latency due to the delayed_job poll interval. Additionally, I need a channel from the agent in Huginn to the daemon in case the agent wants to send messages over the websocket. Both directions can be done quite nicely with HTTP.
I hope this will enable users to combine the WebSocketAgent with the JavascriptAgent to perform simple handshake-dialogs with an WebSocket server (e.g. wait for the connection to open, then send "SUBSCRIBE temperature", then process incoming data events).

[cantino]

That makes sense, I think. Do you have some sample code that's already
available for me to look through before you spend a lot of time
polishing? It will be nice to discuss the plan before you have to do a lot
of changes, but I do think this is a very interesting direction and we
should keep pursuing it.

On Wednesday, February 25, 2015, Martin Skinner notifications@github.com
wrote:

I'm trying to avoid latency due to the delayed_job poll interval.
Additionally, I need a channel from the agent in Huginn to the daemon in
case the agent wants to send messages over the websocket. Both directions
can be done quite nicely with HTTP.
I hope this will enable users to combine the WebSocketAgent with the
JavascriptAgent to perform simple handshake-dialogs with an WebSocket
server (e.g. wait for the connection to open, then send "SUBSCRIBE
temperature", then process incoming data events).

—
Reply to this email directly or view it on GitHub
#192 (comment).

[Mask]

Just a spike so far. I've pushed it to github https://github.com/Mask/huginn/tree/spike/websocket_agent

This just connects to wss://echo.websocket.org and sends a "hello" message. Many values are hard-coded (e.g. the websocket server uri) which will become parameters later on.

[cantino]

Awesome, I'll check this out and get back to you later this weekend!