Mojito is divided into two main workflows: a) middleware, who are responsible for handling the original req, and decide what to do with it, and in some cases. b) dispatching a command thru the mojito dispatcher (we call this the dispatch engine, which happens to be request agnostic).
I think a) is clear, just express middleware. But b) is more complicated, specially because the concept of a command is not well documented. In the short, a command is a simple object that tells what mojit to dispatch, what action to dispatch, some basic configurations for the mojit instance, context and parameters. Also, dispatching an action means we will need an OutputHandler, something that you can easily build since it has a very simple API.
I'm explaining all this because you can create your own layer that dispatches a mojit instance, just like mojito-tunnel-middleware does today. This also means you can have a middleware that handles the websocket and dispatches mojit instances when needed, and flush the response of those executions to the client side.
We are not focus on socket.io at the moment, but eventually we will be writing a couple of examples to people can get the idea and create their own mojits and middleware for it. I will recommend to:
"create enhancement tickets thru github.com/yahoo/mojito so we can prioritize it".
P.S.: mojito 0.7.x, which is going to rely more on express and provide more ways for developers to customize things at the app level, should facilitate this use-case a lot.