On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> 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 =)
Its not really done anywhere else :-(
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. 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).
Sure. that would be handy. But you could also eventualy support Map messages too right?
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.
Well, when the publisher is a pure jms client, he wont be providing a header for the transform type right? What I was thinking is that when the client says SUBSCRIBE with x transform, it basically sets up a contract that given all the JMS message types a well defined transformation to STOMP frames will be done. It could be that a future transform will take a Map messages and turn it into XML and put that in a text stomp frame. But a different transformation might take a Map message and do a binary encoding of the key value pairs. Either way the client will know what to expect because he requested it on the SUBSCRIBE. In addition, a smarter transformer could enhance the subscription's selector so that it does not receive message types that it cannot handle. That way if the client says it can only receive text messages, it only subscribes to text messages.
Here are the use cases I see: Client->Server 1) SEND\n...\ntransformer:text (client tells server it's a text message) 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message) 3) SEND\n...\ntransformer:default (client tells server to use content-length to make determination) 4) SEND\n...\n (no transformer specified - same as #3) 5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use default)
and I also see stuff similar to: 6) SEND\n...\ntransformer:xml-to-map (client tells server it's a xml stomp frame that need to get converted to a jms MAP message)
Server->Client 1) MESSAGE\n...\ntransformer:text (server tells client it's a text message) 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes message) 3) MESSAGE\n...\ntransformer:default (server tells client to use content-length to make determination) 4) MESSAGE\n...\n (no transformer specified - same as #3) 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown transformer - use default)
Sure, but that's just content type information. I do agree we need to set this to something. But it's separate from doing transforms to map from all the JMS message types to the 2 basic stomp types text and bytes.
Does this make sense, or am I missing something?
I think we are starting to converge now. I guess the biggest issues with content type like fields is that there are so many of them. I personally would map content-type -> JMSType since I think they were meant to hold app specific descriptions of the payload. We may want to have the additional header you were proposing to hold information about the STOMP frame - > JMS Message type kind of information. It gets fuzzy here.
Thanks, Nate On 6/13/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > I would suggest that we use a weak form of specification encoding. > > ActiveMQ already uses pseudo-urls in a lot of places, and named > > transforms trump class names, usually: > > > > yeah! URI style configuration rocks! > > > > -Brian > > > > > > > > > > > > > -- > Regards, > Hiram >
-- Regards, Hiram
