On Jun 13, 2006, at 11:42 PM, James Strachan 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.
I don't think that is a very good default, actually. The default
needs to be conservative and try hard to save the information there.
It is not unreasonable that a serialized java object is a valid
payload to a perl client -- it is just another binary payload.
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/
