On 6/14/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 6/13/06, Nathan Mittler <[EMAIL PROTECTED]> wrote: > So it sounds like we're all in agreement on the content-type header. For > text, it would be something like "text" There could be a few values of Content-type which map to text (text/xml, application/soap, application/xml etc). Incidentally the default implementation for sending an ObjectMessage / MapMessage to a Stomp client could be to use XStream to turn it into XML and mark it as text/xml. Otherwise its gonna be extremely hard for a typical Stomp client to read the message.
So if we were to have text, object, and map messages all with a content-type of "text/xml", then we would need another parameter, such as the "amq-msg-type" that tells a JMS-like stomp client (such as CMS) which it is, so it can create the appropriate object to return to the user. I could key off the amq-msg-type and then check the content-type to make sure it's XML, as expected. Then I could parse the XML to create the MapMessage, for example. Not quite sure how ObjectMessages would work, however.
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? Sounds great. -- James ------- http://radio.weblogs.com/0112098/
Regards, Nate
