rabbitmq
socket.io support
Hi,
Just wondering if it will make it easier to support socket.io if you'll be reusing socket.io-erlang (https://github.com/yrashk/socket.io-erlang). Not sure whether it's possible to do use it with rabbit-socks, just wanted to make sure you're aware of its existence and will be glad to help if necessary.
Anyway, thanks!
Hi Yurii,
We are using mochiweb for a few other things, and we have a kind of multi-app hosting thing going on with it (see rabbitmq-mochiweb). How difficult do you think it would be to disentangle socket.io-erlang from misultin enough to make a mochiweb adapter for it?
To be honest I quite like the API style of socket.io-erlang, so it'd be great if we could use it.
Cheers, keep up the great work (erlzmq too)! Michael
Yurii, don't know if you saw, I forked socketio-erlang and started adding mochiweb support. So far, nothing controversial.
However, I would like to add the path into the information that the event listener gets, so it can close the request or socket. In fact, I'd like to be able to "reject" the request or websocket connection if the path is not to my application's liking, and return e.g., a 404. The current API doesn't really allow for this.
This goes a bit further than socketio-node but not in an incompatible way; i.e,. it is still easy to have just the same behaviour as socket.io-node.
Thoughts?
There was a change suggested by @skarab some time ago, and I think it will be a good idea to finally add it. The idea is to insert a generic behaviour before the gen_event and implement a default behaviour that will be that gen_event. This way you can supply any information any way you want. Thoughts?
Not sure I understand the suggestion. Is there a patch or more discussion somewhere?
There is no patch (yet) — it was just a discussion at the Factory. The idea is that right now all the events go directly to a gen_event event manager. @skarab's suggestion was to generalize this a bit — by implementing different behaviours (callbacks) on what to do with incoming clients/messages; and to preserve backwards compatibility, a default behaviour would be to push those events out through gen_event (to replicate today's behaviour). Any clearer now?
Got it, yes. The event handler is quite tied in but it's plausible it can be factored out. I may give it a go ..