On Fri, Mar 20, 2009 at 10:11 AM, Simon Laws <[email protected]> wrote:
> 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. So with your approach, Simon, the pattern we're setting up is something like: "if I have a decision to make wrt how to serialize a response, I might want to look at the request payload to guide my decision." I have to admit, that sounds reasonable and potentially useful across other wire format & binding combinations. This is especially true when dealing with wire formats that are abstract to some degree (e.g. I've got JAXB-serialized-to-XML but it might be in a Bytes or Text msg), or wire formats that have multiple "cases" inherent in their processing (e.g with binding.xxx, the "default wire format" can handle either yyy format or zzz format). (Of course, this assumes we agree that abstract, multi-case WFs should even exist, though WF.jmsdefault sets a precedent here). My concern was that we're adding another column to the "wire format decision matrix", with columns already probably including "binding" and "wireFormat". It's not that we couldn't do the job of coding and documenting this... it's that I'm worried the user will look at the "matrix" we document encompassing all the WFs and bindings and think that this is overly complicated. But ... maybe I'm getting ahead of myself here... we probably need to build our understanding of what a wireFormat behavior does from the bottom-up, one case at a time, so this has been a good place to start/continue the discussion. So let me add one more twist: do we agree that participation in a callback does not add to the "context" here in determining the bytes vs. text default? I.e., if, rather than sending a response to a forward request, I call over the callback interface, should I use 'bytes' as default no matter what? Scott
