Agreed - we should make more use of the Stomp Content-type header; then we can detect "text/plain", "text/xml" etc and use TextMessage on the JMS side and text on the Stomp side etc.
e.g. any JMS message we send over Stomp should always have a Content-type header set so that a Stomp client can do the right thing etc. On 4/24/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > On Apr 23, 2006, at 7:17 PM, Hiram Chirino wrote: > > > How about we make that an optional extensible header that defaults to > > "binary" if not set. All stomp implementations should at least > > support text and binary. Something like: > > > > message-type:text > > We can do server-specific headers now, and can actually cover this > via selecting a message type by inspecting the Content-type header. > > What I am trying to avoid is the situation where a receiver doesn't > know what kind of message to expect, and needs to detect if it is a > byte or text message =/ > > > And activemq would also support some other types such as: > > activemq-map, activemq-stream, and activemq-object where ActiveMQ > > would define the expected body encoding for those types. > > > > Regards, > > Hiram > > > > On 4/23/06, Brian McCallister <[EMAIL PROTECTED]> wrote: > >> I want to correct a design wart in ActiveMQ's Stomp implementation -- > >> originally Stomp only supported text and I implemented messages as > >> text messages. Later I caved and changed stomp to handle arbitrary > >> byte bodies, and used byte messages to handle this. > >> > >> The difference, according to ActiveMQ, is whether the content-length > >> header is specified (if it is not, it goes into text mode and scans > >> for a null byte). > >> > >> I'd like to change activemq to *always* use byte messages. > >> > >> -Brian > >> > > > > > > -- > > Regards, > > Hiram > > -- James ------- http://radio.weblogs.com/0112098/
