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