Sounds good to me. +1
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, June 13, 2006 1:45 PM To: [email protected] Subject: Re: STOMP and JMSType On 6/13/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote: > Just to make clear what the proposed new "hard-coded" logic does: > > 1) If there is no content-length, it's a text message (same as before) > 2) else, if there is no message type, it's a bytes message (same as > before) > 3) else use amq-msg-type to determine the message type > > So this logic is backward-compatible with the existing logic. If the > client does not specify "amq-msg-type", the behavior will be the same as > it is now. > > The STOMP protocol doesn't define a mapping to a JMS system, so as far > as predictability goes, the users just need to follow our logic for the > mapping. They wouldn't be able to change the mapping, like they would > with a pluggable framework, but they shouldn't need to. They just code > their clients against the mapping that we publish online and they'll be > up and running. > > I'm getting the feeling that the main reason for leaning toward the > pluggable framework is to support a BytesMessage-only paradigm. In a > STOMP-only world this probably makes sense. You're just and receiving > "stuff". But when you're bridging between Stomp and JMS, I'm not sure > why a client would ever want this restriction. It seems like if you > want BytesMessages to come out the other end, then you just follow our > mapping logic to make that happen, which really is as simple as > including "content-length" (which you would have to include for a true > bytes message anyway) and leave off "amq-msg-type" (which you would by > default). > > Even if you were to implement a pluggable framework, you would still > need to have some sort of application metadata like the "amq-msg-type" > header. Assuming our framework is comprised of a bunch of message > transformers that go between raw bytes and ActiveMQMessages, the default > transformer for the STOMP transport would do this mapping the way I've > proposed above. So you wouldn't be eliminating the need for the > "amq-msg-type" header, you'd just be pushing around the logic that uses > it. > > So I guess I'm still not seeing the bang for the buck ... it seems like > the "hard-coded" solution works for all cases that we've defined so far. > I'd rather just get this functionality in because I think it's useful > and people have been asking for it. I'm all for continuing to discuss > the pluggable framework, but it seems that that is a separate issue from > what I'm trying to do here (...and probably literally a separate JIRA > issue). I agree. But instead calling the header 'amq-msg-type' (which does not explicitly convey that a transformation is being used), I'd like it to be called 'activemq-transformation' set to a class name of the transformation (or something that maps to a classname, like we do for our service discovery). and this would be header that is not carried with the message, it's a header that controls the send and subscribe operations. > > Regards, > Nate > > > -----Original Message----- > From: Brian McCallister [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 13, 2006 12:20 PM > To: [email protected] > Subject: Re: STOMP and JMSType > > > On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote: > > > James, > > I think that's what we're proposing here. I proposed "amq-msg-type", > > but I suppose "content-type" is just as good. I think Brian's main > > concern (Brian, correct me if I'm wrong) is that he'd like the mapping > > of stomp message to AMQ message type to be pluggable, not hard-coded. > > Actually, my first choice would be hard coded to bytes message, > period, finished =) > > We cannot do this without breaking backwards compatibility, which I > have been presuming we don't want to do. > > The most important thing, to me, when mapping from Stomp to JMS is to > have it be very predictable. I don't want to ever have someone have a > JMS client listening for stuff from Stomp and having to guess at the > message type. As such, the default should be "it is X." If they need > some other mapping, I would suggest that they look at some kind of > transformer service which republishes messages. > > If we are going to have more complicated mapping, I want to either > make it super crippled: a default "compatibility mode" and a strong > recommended "5.0 mode." The next step is to make mapping pluggable, > but don't make a big deal out of it. As ben Laurie would say, a > European style API. > > That is the external point of view. For the internal point of view, > the cleanest implementation I can think of is to have an interface > which takes a Send (or something like) and returns an ActiveMQMessage. > > I am quite strongly against using using application level metadata > (which content-type is in Stomp and JMSType is in JMS) for mapping > information. I am also quite against every client having to specify > what to map the message to as the client should be able to be > independent of the particular implementation. I think it is a very > bad idea to require the client to add the mapping to every message. > > -Brian > > > -- Regards, Hiram
