JSON basic type notation for header values
33 views
Skip to first unread message
Dejan Bosanac
Jun 15, 2010, 3:52:52 AM6/15/10
to stomp...@googlegroups.com
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
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
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
Hiram Chirino
Jun 15, 2010, 5:38:24 AM6/15/10
to stomp...@googlegroups.com
Sounds like this falls into the 2.0 category.
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://fusesource.com/
Dejan Bosanac
Jun 15, 2010, 8:24:18 AM6/15/10
to stomp...@googlegroups.com
Yeah :)
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
brianm
Jun 15, 2010, 11:31:10 AM6/15/10
to stomp-spec
All of the headers in the protocol *are* strings. A given
implementation is assumed to have conventions (selectors on SUBSCRIBE
destinations, etc) but they are specific to the implementation right
now. I shy away from trying to mandate encoding of things like this --
though i certainly think shared conventions for compatible servers
(ie, JMS semantics or AMQP semantics) would be very valuable.
-Brian
implementation is assumed to have conventions (selectors on SUBSCRIBE
destinations, etc) but they are specific to the implementation right
now. I shy away from trying to mandate encoding of things like this --
though i certainly think shared conventions for compatible servers
(ie, JMS semantics or AMQP semantics) would be very valuable.
-Brian
Tom Jenkinson
Jun 16, 2010, 11:50:51 AM6/16/10
to stomp-spec
Hi,
I am new here but would just like to "vote" for this functionality to
be defined as early as possible.
Currently we need to encode the "headers" of our messages in the body
of the message and use a form of content based routing to determine
the route a message should take.
It would be absolutely perfect if we could encode the "numeric"
content (float, double, int, long, short, boolean) in the message
headers so that we can benefit from routing provided natively by the
message server, rather than relying on an ESB or homebrew solution to
do this for us.
We would be happy with the proposed JSON notation.
If the functionality was there, we would definitely be using it today!
I do take Brian's point below, but I feel as if relying on possibly
incompatible conventions between vendors could diverge the user base
in this area at least.
Tom
http://www.jboss.org/blacktie
On Jun 15, 8:52 am, Dejan Bosanac <de...@nighttale.net> wrote:
> 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
>
> Cheers
> --
I am new here but would just like to "vote" for this functionality to
be defined as early as possible.
Currently we need to encode the "headers" of our messages in the body
of the message and use a form of content based routing to determine
the route a message should take.
It would be absolutely perfect if we could encode the "numeric"
content (float, double, int, long, short, boolean) in the message
headers so that we can benefit from routing provided natively by the
message server, rather than relying on an ESB or homebrew solution to
do this for us.
We would be happy with the proposed JSON notation.
If the functionality was there, we would definitely be using it today!
I do take Brian's point below, but I feel as if relying on possibly
incompatible conventions between vendors could diverge the user base
in this area at least.
Tom
http://www.jboss.org/blacktie
On Jun 15, 8:52 am, Dejan Bosanac <de...@nighttale.net> wrote:
> 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
>
> Cheers
> --
Reply all
Reply to author
Forward
0 new messages