Stomp and none-string message headers

[tomjenkinson]

Hi,

In the BlackTie team, we are looking to the availability of Stomp natively within HornetQ:
https://jira.jboss.org/jira/browse/HORNETQ-129

One question we do have is do you plan on supporting numeric header properties types or just Strings like StompConnect currently does?

The reason I ask is because we would like to be able (from C++) to send messages to HornetQ that could be routed (by the HornetQ divert mechanism) but the shortcoming of this appears to be that it is not possible to do this with StompConnect as it assumes that all none-standard headers are Strings. We have our own Jira related to this atm:
https://jira.jboss.org/jira/browse/BLACKTIE-125

Do you have any suggestion for us whether you see it being feasible to do this?

Thanks in advance,
Tom

[mjustin]

"tomjenkinson" wrote:

One question we do have is do you plan on supporting numeric header properties types or just Strings like StompConnect currently does?

This is already on the list for version 1.1 of the Stomp protocol:

http://stomp.codehaus.org/Stomp+v1.1+Ideas

JSON basic type notation for header values

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

Many other suggestions are on this list. The further standardization of the Stomp protocol however has not seen much progress as far as I can see. With ActiveMQ, OpenMQ, RabbitMQ and now HornetQ supporting Stomp the development (and clarification) of the specification might become more critical to avoid incompatibilities.

[tomjenkinson]

Thanks for the response Michael, I wonder if there is no time-scale for Stomp 1.1, perhaps hornetQ could provide this capability in a none-standard extension to the 1.0 spec in the interim?

Although implementing this as JSON would be great, an alternative could be something like overloading the key field? E.g. Key of "float:orderVal" value of "1.2"?

I wonder, if providing an extension is not feasible, is there any other recommended way to send messages from a C client to HornetQ that can pass in numeric header fields (for HornetQ divert usage)