View Full Version : JSMP (JSON Message Protocol for WebSockets)

04-07-2011, 02:12 AM
I've put up a draft for JSMP at JSMP Draft Page (http://hessian.caucho.com/jsmp/). The spec can be used by anyone looking at using JSON with WebSockets.
Now that WebSockets is getting close to reality, we get to create application protocols on top of it, and JSON is a natural payload format.

JSON itself, however, doesn't quite have enough structure for a general messaging protocol, so JSMP adds a few simple things:

types: messages are typed, allowing for object-oriented services
addresses: the application can be decomposed into services on the server and client addressed by mail-like addresses (user@example.com)[/li]
query-response: both unidirectional and query-response pairs are enabled by JSMP.

Since most JSON/WebSocket applications will want these capabilities, JSMP gives a standard syntax for anyone looking to get an application running rather than spending time inventing a totally new protocol.

We're using a similar architecture internal to Resin for our own clustering, although we're using HMTP (hessian) instead of JSON.

04-08-2011, 01:39 AM
Based on feedback, I've updated the draft to v1. Each message is now a correct JSON message.

{"value" : "my-value"}]

06-01-2011, 09:16 AM
Hi there,

I saw that the query grammar for message-error is missing (http://hessian.caucho.com/jsmp/draft-ferg-jsmp-v1.html#anchor11). It is not very clear if after the payload there is also an error payload. Could you please clarify this point.

In addition, it will be great to have a Streaming transports similar to Bayeux: http://svn.cometd.com/trunk/bayeux/bayeux.html

06-07-2011, 02:08 PM
I have a proposition regarding the packet parts separators. Currently, each packet part is wrapped in quotation marks ( " ) and separated from the other with comma ( , ). Since the payload is in JSON which also uses the same symbols, I would like to propose substituting JSMP separators with other symbols like single apostrophe ( ' ) and semicolon ( ; ). I think this will add more clarity to the protocol and will ease underlying implementation.

06-07-2011, 04:02 PM
Thanks for both comments. I can easily add the message-error.

I'll need to change the grammar syntax to the official IETF one.

The idea, though, is that each message is a well-formed JSON array. So technically you don't need to do any parsing if you have a JSON parser already. (Although, it's also designed so an efficient parser can skip that step.)

06-20-2011, 07:07 PM
I think it will be a good idea to standardize which of the two addresses should be the source address and which the destination address. Currently, it's clear only from the examples that the first address is the destination address. To my understanding this is not necessarily always true.