Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z6Ipv07/SwD0ar7u7lLsHZARKCSffNfqyJRsrkY0I+MxX2olh22Gsso02e7aFyoyt2Bk/hq3KjQZTo8WD4wqGh2VAyw77/+StJYsOf7pg+qh/vrBVgqqmbjj8pPlk3Bz0Ipqb2qAx3Y9kSYk/4df+AOwSVhSl32e3nP2ag236JI=
Message-ID: <ec6e67fd0606130756o51095939ub8a82bbf7dc8793b@mail.gmail.com>
Date: Tue, 13 Jun 2006 15:56:46 +0100
From: "James Strachan" <james.strachan@gmail.com>
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType
In-Reply-To: <8a6feb940606130321s13689a34l8a9b85e9329087f3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <7743F17344E95A4CA78A3E53A7AF496B5C2EE1@corpatsmail1.corp.sensis.com>
	 <55EBC799-271F-4822-BC46-7650B1375762@apache.org>
	 <8a6feb940606121614i91ed695h782a2f421ce0bacc@mail.gmail.com>
	 <AA5462A2-23F9-48D8-ADB2-AF0EB1CCB3ED@apache.org>
	 <8a6feb940606130321s13689a34l8a9b85e9329087f3@mail.gmail.com>

FWIW I'd like to have content-type header support. Couldn't we then
use content-type as the standard header that any Stomp-JMS bridge
would use to decide if something is a TextMessage or a BytesMessage?

On 6/13/06, Nathan Mittler <nathan.mittler@gmail.com> wrote:
> I think that clears things up for me a bit - what you're proposing makes
> sense.  I'll poke around today and see what I can come up with.
>
> Thanks,
> Nate
>
> On 6/12/06, Brian McCallister <brianm@apache.org> wrote:
> >
> > 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
> >
> >
> >
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/