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
