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)
mapping.
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?" =)
[snip-and-rearrange]
> 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.
Yes.
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.
-Brian
