On Jun 12, 2006, at 4:14 PM, Nathan Mittler wrote:
Agreed ... using the "type" header is not an option.
--- From the bug report ---
It isn't possible to reuse the "type" header (JMSType) for the
purpose of sending through the information as to what type of message
it is (text or bytes). So this means that we need to add another
activemq extension header. I propose "amq-msg-type".
--- / From the bug report --
I like this a lot better, and think it would be a reasonable default
rule for mapping in 4.X.
I am not convinced we need this, but I much prefer it to a hardcoded
transform, as this would allow for much more useful transforms (ie,
aplication-aware).
Although I agree conceptually, I'm thinking this might be a bit of an
overkill for the task at hand.
Agreed. I just hate to layer on another backwards compatibility issue
beyond what we already have. By designing it to be forward compatible
with an arbitrary mapping we can grow into a future solution more
easily. Once we add this header we will need to support it ~forever.
Right now the STOMP transport only works
with bytes and text messages, and creating this transform model
won't change
that. I think if we one day decide to refactor the transport to
accept
other message types - that would be the time to make this sort of
change.
What if I want to switch on "Content-type" to decide between text or
bytes? It is a common header to use, but is not part of the spec (as
stomp doesn;t care, but is happy to pass it along). This makes more
sense to me in terms of mapping between Stomp and JMS, but it is not
compatible with switching on a specific content header.
The mapping between Stomp and JMS is actually rather important to get
right as it is the low level interop mapping between various
platforms and Java. As such, I want to make sure we are building
towards a correct solution.
Aside from all this, controlling the protocol <--> (semi-)protocol
mapping should be a configuration thing, not a flag the client must
put on every message it sends.
The end goal for me is to have all messages coming in from the Stomp
adaptor be bytes messages, unless someone has an overriding need for
something else (quote possible). The current behavior is pretty bad
as a default, but we just released 4.0 with it, so we are stuck until
we make another backwards incompatible release (5.0).
In 4.1 we can add the amq-msg-type header to allow people to force
things to bytes (or text) but for the 5.0 end game we will need to
make the mapping pluggable in order to make the upgrade path as easy
as possible. if we are going to need pluggable eventually, why not do
it now in order to allow people to fix the bytes/text mistake (I can
say it is a mistake, I wrote it =) at the server level instead of
having to add a header to every message.
We have, then, three configurations which people are likely to want:
1) Current (3.2 and 4.0 compatible) one which is made more palatable
by letting the client specify via the amq-msg-type.
2) Map everything to bytes, which I would like to make the default in
5.0.
3) Map everything to Text (which is what I would actually use if we
had it as I convert all the bytes ones I send now into strings anyway).
If we are going to have it be sufficiently pluggable to support these
three, we should consider letting users provide their own.
-Brian
