Sure. that would be handy. But you could also eventualy support Map messages too right?
That's certainly a possibility. We'd just have to come up with a form for the body of the stomp frame in that case - shouldn't be terribly difficult.
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.
Ok, I think I'm starting to get it ... finally :). So it sounds like the main idea for the transformers is not bytes/text messages, which are low-level protocol-specific stuff ... rather, it's more like application-level transforms. So the application layer might say, I want this to become SOAP at the broker or something like that. What I need is just a protocol-specific header (I've been calling it "amq-msg-type") that tells me how to treat the payload (in raw JMS message terms). So I think we're talking about two different issues. In JIRA issue 739, I was addressing the protocol-level need for a message type. It sounds like we need another issue to capture the transformation refactoring to support adapting to other message types. --
Regards, Hiram
Regards, Nate
