This page contains a wish-list for version 1.1 of the Stomp protocol. Please feel free to add things you see missing in the current Stomp specification. This list will grow into a final 1.1 specification over time. For any discussion, please join some of our Mailing Lists
There's no explicit way to NAK a message (i.e. indicate that processing that message failed).
"Store and forward" is a common use case for async messaging that's difficult to satisfy with the current protocol: collect messages in a queue, eventually a client connects, requests messages until the queue is empty, and then disconnects.
Adding a "receive" verb to the protocol would satisfy this requirement. It would use the same headers as the "subscribe" verb but would return immediately with either a message or an indication that there weren't any messages.
toby at caboteria dot org
Wire format negotiation
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.
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)
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-map-json) of the
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.
Allow a consumer to consume different types of messages. Message transformation allows consumer to subscribe with certain type of transformation, after which it will expect only one type of messages (text, object, map or byte). We should add one more optional header to
MESSAGE command called
message-type. This header can have the same values as transformation header used on
jms-object-xml for example. This header value instructs the broker to do the appropriate transformation, even if it is not specified by
transformation header. Also, the broker can automatically transform messages sent with "native" JMS clients and consumed by Stomp consumers. This header can also help Stomp consumers to determine the type of the message, if they are consuming from destinations that contains multiple-type messages.
(stomp 1.0 supports binary messages, that is the very reason there is a content-length header)
content-encoding header for
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.
Optional Keep Alive protocol.
Right now we have to depend on the OS
to detect socket failure to time out a dead client. Would be nice if
the client could optionally agree to send a Keep Alive commands when
the connection is idle. That way the sever can detect dead clients
Perhaps standardize a 'host' header in the CONNECT frame to specify
the host name that the client is connecting to. This would allow
implementing virtual hosting where multiple DNS host entries point at
the same STOMP server.
(this comment must refer to an older version of the spec, since the v1.0 protocol does specify a required
message-id header that indicates which message is being acked)
The Stomp specs at http://stomp.codehaus.org/Protocol does not detail the ack behavior nor does it recommend or hint anything.
Introduce a new ack mode in Stomp SUBSCRIBE header:
The chosen header is called 'client-individual'; to reflect that ACKs are still client initiated PLUS "individual" to
declare that the client intends to acknowledge individual messages by message-id, not in batches as with simple 'client' ack mode.
Kindly suggest a another header name if you can think of a more appropriate one.
Ping just verifies that the server is alive. The server should respond with "Pong" to indicate that it is indeed there.