On 6/14/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram > Chirino > Sent: Wednesday, June 14, 2006 12:40 PM > To: activemq-dev@geronimo.apache.org > Subject: Re: STOMP and JMSType > > On 6/14/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > > On Jun 13, 2006, at 3:06 PM, Nathan Mittler wrote: > > > > > So it sounds like we're all in agreement on the content-type > > > header. For > > > text, it would be something like "text" and for bytes it would be > > > "application/octet-stream". So this would not be an application-level > > > header, but would be used by my stomp client code to determine > > > which message > > > type to create. > > > > Content-type is application level. I was suggesting it for your use > > case where you want to know what to convert a bytes message into in > > your C++ library =) > > > > Agreed! the app in this use case is the C++ client lib. so the c++ > client lib could set the content-type to control a custom transformer > so that sent JMS messages are exactly as the C++ stomp lib wants them > to look like. 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". 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").
So here's a link to everything that is in the spec currently: http://stomp.codehaus.org/Protocol It's a WIKI so you can edit it and improve the spec. I think that a the big missing piece in the spec is that there is no specification of how STOMP messages get mapped to JMS messages. Since this is missing, there is no provider independent way of sending JMS messages from STOMP. Since every implementation could map a STOMP message to JMS messages differently. I think we need to add a "STOMP Message to JMS Message Mapping" section that providers SHOULD comply with if the provider also implements a JMS interface. The great part is since this is missing, you can make this whatever you want!
> > 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. > > 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. > 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.
Ok great!
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.
Sure!
BTW, what is the timeframe for 4.1?
I like to aim for 1 month, and accept slipping a month or two :) I would say it's mostly dependent on new feature progress and code stability.
> Also, as offshoot idea on #2, is a provider allowed able to expose > additional verbs/operations to clients? Kinda like how SVN/DAV does > for HTTP? > > > > If we're all in agreement with that, then it seems to make sense > > > that the > > > default functionality of the broker be modified to handle content- > > > type in > > > this way. > > > > No. activemq-transformer would provide the JMS type mapping to > > override the default. > > > > I suggested that you use content-type (not required by stomp) to > > decide if something is text or a byte stream. Transfer-encoding is > > also useful for this. > > > > :-) > > > > > And if that's true, then it seems like this particular issue is > > > resolved. > > > This way, we get it into the 4.1 release with no problems. We can > > > create > > > another issue to do the refactoring as you've suggested ... which will > > > probably take a little more time and several conversations to get > > > right. > > > > > > How does this sound? > > > > > > Nate > > > > > > On 6/13/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > > >> > > >> On Jun 13, 2006, at 1:50 PM, Nathan Mittler wrote: > > >> > > >> > Could you guys point me to a place in AMQ where this sort of thing > > >> > is being > > >> > done? That would save me a lot of searching =) > > >> > > > >> > I'm viewing this problem from the client side - the Stomp C++ > > >> > client that > > >> > Tim Bish and I are writing currently supports text and bytes > > >> messages. > > >> > > >> Within a general Stomp client, I would suggest that switching on JMS > > >> message types is not a productive goal. Using Content-type here makes > > >> a lot more sense, I think. . It would make a lot of sense to set it > > >> for text messages going out to Stomp if there is not one already > > >> supplied. > > >> > > >> Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a > > >> specific server implementation is probably not a general solution > > >> (though is fine if it is specifically an activemq client which > > >> happens to use stomp for transport). > > >> > > >> > So when I get a stomp frame in, I need to map it back to a text or > > >> > bytes > > >> > message. We chose to do this for a couple of reasons: 1) to give > > >> > JMS users > > >> > a familiar interface and 2) to provide a simple interface for > > >> > reading and > > >> > writing text messages (e.g. xml). > > >> > > >> Content-type: text/xml > > >> > > >> -- > > >> > > >> Content-type: application/octet-stream > > >> > > >> > With that said, I'm not seeing how I can do that mapping if the > > >> > transformer > > >> > is provided only in the SUBSCRIBE. A client could potentially get > > >> > a variety > > >> > of message types from a single subscription. I think it would have > > >> > to be > > >> > part of the MESSAGE frame, rather than the SUBSCRIBE. > > >> > > >> SUBSCRIBE > > >> activemq-transformer: com.example.ContentTypeMapper > > >> > > >> > Here are the use cases I see: > > >> > > >> s/transformer/activemq-transformer/g > > >> > > >> I like the namespace. > > >> > > >> > Client->Server > > >> > 1) SEND\n...\ntransformer:text (client tells server it's a text > > >> > message) > > >> > > >> +1 > > >> > > >> > 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes > > >> > message) > > >> > > >> +1 > > >> > > >> > 3) SEND\n...\ntransformer:default (client tells server to use > > >> > content-length > > >> > to make determination) > > >> > > >> -1 Give it a descriptive name so that we can change the default > > >> without breaking these. > > >> > > >> > 4) SEND\n...\n (no transformer specified - same as #3) > > >> > > >> +1 > > >> > > >> > 5) SEND\n..\ntransformer:bob (client gives server unknown > > >> > transformer - use > > >> > default) > > >> > > >> Return an error -- do not quietly swallow this. > > >> > > >> > Server->Client > > >> > 1) MESSAGE\n...\ntransformer:text (server tells client it's a text > > >> > message) > > >> > > >> +1 > > >> > > >> > 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a > > >> bytes > > >> > message) > > >> > > >> +1 > > >> > > >> > 3) MESSAGE\n...\ntransformer:default (server tells client to use > > >> > content-length to make determination) > > >> > > >> -1 same as #3 above > > >> > > >> > 4) MESSAGE\n...\n (no transformer specified - same as #3) > > >> > > >> +1 > > >> > > >> > 5) MESSAGE\n...\ntransformer:bob (server tells client to use > > >> unknown > > >> > transformer - use default) > > >> > > >> -1 same as #5 above > > >> > > >> > > >> This does highlight that we have two real transform cases, send and > > >> receive if we support CONNECT or SUBSCRIBE level transformers. We can > > >> infer the correct direct on MESSAGE and SEND, but not the others. As > > >> this would make the interface have all of two methods, I am quite > > >> happy combining it. > > >> > > >> Alternately we can have different headers on SUBSCRIBE and CONNECT > > >> > > >> -Brian > > >> > > > > > > > -- > Regards, > Hiram
-- Regards, Hiram
