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.
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. 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
