activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@apache.org>
Subject Re: STOMP and JMSType
Date Wed, 14 Jun 2006 16:10:13 GMT
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 =)

> 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 <brianm@apache.org> 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
>>


Mime
View raw message