If you say that it supporta HTML5 you should say how it supports websockets . I read the whole documentation it was never mentioned how it supports websockets. If you boast of html5 support tell me this

Hi,

Basically, as far as I understand, there is no model for supporting websockets in Mojito. There is something called the TunnelProxy mojit, which is an RPC model for bidirectional comms, which you can look at in the code of mojito, but I do not use it so I have no idea what it's good for, except that RPC is not what websockets are about.

You can also REST-ify your service and use mojito lib REST to access your server. This covers many use cases. This is what the Yahoo devs told me in last November to use.

I also need this functionality and am thinking of creating a mojit that handles the socket.io loading and presents this resource to all other mojits via the mojit proxy in an event driven manner. That's the client side. On the server side, the complication with websockets is that you are adding to nodejs an additional input channel besides http, so you will need to add some middleware to handle the websocket port and make sure that node's singlethreaded model is not compromised (no blocking allowed). We need those signals for a pub/sub to our mongoDB database...

I also found this: https://github.com/yahoo/mojito/pull/348

Not clear what jintao did there... The HTMLFrameMojit to my knowledge does not implement anything to do with websockets or additional channels at the moment. (also it shouldn't)

I hope some mojito engineers read this and respond soon.

Cheers Ron

Hey @Ronald,

Let me try to help by clarifying few things:

• One thing is to produce the initial HTML that boot the application in the client side (which is what HTMLFrameMojit does today, or whatever mojit to use to build the frame), and another very different thing is to create a communication channel between client and server once that app is already running in the client runtime.

• Mojito REST api is just a wrapper around Y.io, and I will recommend not to use it.

• Mojito is divided into two main workflows: a) middlewares, who are responsible for handling the origina req, and decide what to do with it, and in some cases. b) dispatching a command thru the mojito dispatcher. I think a) is clear, just express middlewares. 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 a middleware 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".

Best Regards, Caridy

@Caridy,

thanks for shedding light on some of the mystery around the dispatching and output-handlers. It would be great if where you are headed could be graphically represented, as I understand that we are reimplementing some of this stuff having been on our own dev road since mojito 0.4.4.

Will put in some tickets.

Best regards, Ron

@Caridy,

our entire backend is RESTified - so you can automatically make your controller serve REST answers, by adding a REST route. Our RESTController automatically makes your controller into a REST server for the models in your mojit. This supports HTTP actions PUT, DELETE, GET, etc.

So why not use mojito.lib.REST?

Ron