On 10/25/06, robottaway <[EMAIL PROTECTED]> wrote:
Could I patch it up so that we have a 'sendTextMessage' method, and then the normal 'send' method (for binary)? This makes a little sense to me, in the case that someone wants to send a message consisting of text as a binary message.
This sounds ideal! It looks like you guys are using the content-length header as the only
indication of text vs. binary in the STOMP transport for AMQ. I've seen talk
Right.
of setting up the transport object so that it would handle a 'type' header which would allow the user to have a content-length header but still marshall the message into the AMQ system as a text message. I believe this would be done using the header 'type' set to 'text'. If this is not what happens then I will submit the client so that others can use it to submit TextMessage messages into AMQ from STOMP.
I think that what's going to happens is that the existing simplistic system is going to remain as is. I think STOMP will start evolving some extensions that do more fancy mappings of STOMP frames to JMS messages. And the STOMP client will select which mapping strategy it expects to be used when it connects. something like: CONNECT frame-translation: default or CONNECT frame-translation: json So one day we might develop a ruby client that uses the json translation and the messages are encoded in JSON for example. This could allow stomp clients to receive Map messages too. --
View this message in context: http://www.nabble.com/Ruby-STOMP-client---TextMessage-tf2504913.html#a6994038 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
-- Regards, Hiram Blog: http://hiramchirino.com
