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. 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). 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. 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) 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) Does this make sense, or am I missing something? 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
