> complexity into our wire format behaviors (not that I couldn't be
> convinced).    It's certainly simpler to describe the wireFormat if we
> say there is a default used for serialization, period, than to have to
> introduce the request-format-as-context into the mix.

A single static default wire format is simpler to code/describe. I
don't think it's as user friendly but I could live with it.

>
> Another point: IMHO, I think in general  non-SCA <-> SCA binding.jms
> interactions maybe should be thought of as requiring wireFormat
> configuration, even if that configuration choice happens to be using
> wireFormat.jmsdefault. Maybe it involves some burden on the user to
> realize this fact.   In SCA<->SCA flows, on the other hand, I would

Some burden on the documentation to point it out I guess. I agree that
if people are including binding.jms they are probably expecting to
communicate with non-SCA systems. I don't think we should make it
mandatory though to have to modify the default behaviour to make this
work.

> expect it's more important to "just work" without any extra config.
> In this SCA/SCA case, though, if both sides implement the OASIS
> binding.jms spec, they can handle either bytes/text, so this question
> isn't super-important.
>
> Scott
>

Simon

Reply via email to