activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: STOMP and JMSType
Date Wed, 14 Jun 2006 17:46:30 GMT
On Jun 14, 2006, at 10:21 AM, Mittler, Nathan wrote:

> Ok, so application-level is referring to the C++ library, not the user
> of the library?  If so that eliminates the need for another header  
> like
> "amq-msg-type".

We still want the transform header for the stomp adaptor though, in  
order to allow people to migrate to 5.0 style (all bytes byt default)  

> How do we make this become part of the stomp spec?  When we do, we
> should define the list of valid values for it (e.g. "text" and  
> "bytes").

We don't. It is how we map it in ActiveMQ, it is not part of the  
protocol itself. I think that having an appendix with recommended  
mapping is a good thing, though.

Ditto an appendix on making good use of it -- Stomp Layer 2 =)

>> So I'm starting to think there are 2 main use cases:
>> 1) I want to have portable STOMP client that work on other providers.
>> Then you accept that you can not tightly integrate with an existing
>> JMS network in a portable way.  For example they would not be able to
>> send and receive JMS Map messages.  Since stomp does not specify what
>> those messages would look like on the wire.  This means that STOMP
>> needs to define how a portable mapping of JMS ByteMessage and
>> TextMessage to STOMP Messages.  I think what we have today is very
>> close to this.  We may just need to formalize it a little more in a
>> document so that other providers could implement the same STOMP to  
>> JMS
>> mapping.  Of course, this mapping has to stay simple.

Simple is good -- ask, "What would Alan Kay do?" =)


 > So right now, I'm just concerned with #1.  I'd like to make the first
 > crack at our client as STOMP vendor independent as possible ... and
 > we're only doing text and bytes messages for the first cut.

If you think it is important to have something specifically for text  
messages in the C++ client, I would switch on content-type using mime  
type stuff a la SMTP and HTTP. This, though, is like the magic  
handling of www-url-encoded form stuff in servlets -- it is a common  
case made more convenient in the API (which is a good thing).

>> 2) You have a STOMP client that does not mind intimately knowing  
>> about
>> ActiveMQ.  Then it can request transformation on the the send and
>> receives.  That transformation could totally change all the STOMP
>> rules about the headers for for the messages coming in and out.   It
>> might use the content-type to hold the JMS message type: bytes, text,
>> object, map, etc.  and other headers like jms.Type to hold the  
>> JMSType
>> headers.  Also the payload encoding could be fancier.


>> So by default, I think it should work like case #1, if you want to  
>> use
>> case#2, then you use the transform header options.  This gives us
>> backward compatibility but for your " C++ stomp client that exposes a
>> JMS like API" use case, I would think it falls under use case #2.

> If we're in agreement that the two use cases you've identified are two
> separate JIRA issues, then we can just create a second JIRA for #2,  
> and
> I can go off and implement #1 in the broker.

Not sure we are all talking the same thing yet, but we are definitely  
getting close.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message