I think ByteMessage is preferred by some messaging folks as it avoids some of the encoding issues that can arise when using TextMessage across platforms, so maybe bytes should be the default?
...ant On Thu, Mar 19, 2009 at 5:48 PM, Kaushik Mukherjee <[email protected]> wrote: > Your question about the MAY clause reminded me of another point. I am > adding a flag to configure the message type that is sent, and I was > assuming that text message would be the default if no message type is > specified, but there is really no indication in the spec as to what we > should use as the default. We could either choose a default format if > nothing is specified, or we could require the message type always be > set explicitly. I would prefer to have a default type which we can > override with an optional attribute. Initially I was thinking of > something like this... > > <wireFormat.jmsdefault sendBytes="true"/> //default is false > > but I like what you suggested better so we can explicitly configure > either format: > > <wireFormat.jmsdefault sendFormat="bytes"/> //default is text? > > -Kaushik > > > On Thu, Mar 19, 2009 at 12:54 PM, Simon Laws <[email protected]> > wrote: >> ...snip >>> Most of the behavior described here is clear to me, except for what >>> the default message type should be for a response. For instance, if an >>> SCA service were to receive a bytes message, should the service >>> default to responding with a text message, or should it respond with >>> the same message type as the incoming request? It seems reasonable to >>> assume that a non-SCA client might expect the response to be of the >>> same type as the request, but I can see this being argued both ways. >>> Any thoughts on this would be appreciated. >>> >>> Thanks, >>> Kaushik >>> >> >> My vote would go with replying with the type you received unless a >> particular type has been specified. >> >> Are we proposing to implement the "MAY" clause and allow the format to >> be specified, e.g. something like... >> >> <wireFormat.jmsDefault sendFormat="text"/> >> >> or similar? >> >> Simon >> >
