Stomp v1.1 thoughts – Dejan Bosanac

Update: There is now a wiki page on Stomp site for this, please go there if you are interested in Stomp v1.1

As discussed in this thread some time ago, there is a need to start working on Stomp version 1.1 protocol specification (and implementation), if nothing else then to support types for message properties. I would like to discuss some of the ideas regarding this, before I start working on it. So any thoughts and comment are more than welcomed.

We kind of agreed that we need wire format negotiations in order to make clients and brokers understand each other on what version of the protocol will be used. I think the best place to achieve this is during the connection procedure.

The client can include the version header into the CONNECT command frame, indicating the highest version of the protocol it supports. If there is no version header, version 1.0 is assumed (supports backward compatibility).

The server responds with CONNECTED frame and it can also include the version header, which also indicates the highest version of the protocol implemented. The lack of the version header assumes version 1.0.

Now since both the client and the server knows capabilities of each other, they can use the highest version they both support.

A few examples:

CONNECT
login: <username>
passcode:<passcode>
version: 1.1

^@

CONNECTED
session: <session-id>
version: 1.1

^@

version 1.1 will be used.

CONNECT
login: <username>
passcode:<passcode>
version: 1.1

^@

CONNECTED
session: <session-id>

^@

version 1.0 will be used.

Now the features I would like to see in this new version.

First of all, support for JSON basic type notation for header values.

Currently header values are interpreted as plain String, which makes usage of selectors with numerical values impossible with Stomp.
The idea is to support following notation for header values:
- Number (integer, real, or floating point)
- String (double-quoted Unicode with backslash escapement)
- Boolean (true and false)
- Array (an ordered sequence of values, comma-separated and enclosed in square brackets)
- Object (collection of key/value pairs, comma-separated and enclosed in curly brackets)
- null
I’m not sure if we should include “message transformation” feature (implemented in ActiveMQ already, unfortunately not documented well), which allows you to do transformation of frame content to object, map or byte messages according to the transformation header provided. Currently, support for XML and JSON encoding
is supported with the following values (jms-byte, jms-object-xml, jms-object-json, jms-map-xml, jms-map-json).

So for example, the following command
```
SEND
destination:/queue/TEST.Q
transformation:jms-map-xml

<map>
  <entry>
    <string>name</string>
    <string>Dejan</string>
  </entry>
  <entry>
    <string>city</string>
    <string>Belgrade</string>
  </entry>
</map>

^@
```
would send a map message to the queue.
Support content-encoding header for SEND and SUBSCRIBE commands allowing to send gziped and base64 encoded content.

I would prefer to send and receive binary messages as base64 encoded text, since it seems more natural to me for this kind text-based protocol. Again, this introduces the concept of binary message to Stomp protocol, which I’m not sure we want to do. But surely, gziped content would be appreciated in many contexts.

All this looks great, but adds a lot of new concepts to simple text-oriented protocol, such as map and object messages for example. As useful as this can be in the JMS context, I’m still not sure whether this should be included in protocol for all those people wanting just to send and receive plain text messages. But on the other hand, people always can stick with the version 1.0 and let all others with more sophisticated demands to have a standardized protocol for their needs.

Since these are just initial thoughts, all comments are more than welcomed. Also, if you have any new “requirements” you would like to see in Stomp, now it’s time to come forward.