RE: [ws-caf] three forms of context (was RE: [ws-caf] [Bug 135] New: participating-services list needs to have defined semantics and modification mechanisms or be removed)

[Mark Little <Mark.Little@arjuna.com>]

Peter, I agree that we need to discuss this. In that light, can you expand on 
why you think having multiple protocols inhibits interoperability? Ignore the 
mandated versus optional argument at the moment, and let's assume all are 
mandated to be a compliant implementation (we can relax restrictions later).

Mark.

>===== Original Message From "Furniss, Peter" <Peter.Furniss@choreology.com> 
=====
>In considering the slightly-RESTful participating-services facility (see
>other message) I realised we have now got three different forms of
>context:
>	propagated by value
>	propagated by reference, dereferenced by ContextManager
>getContents
>	propagated by reference, dereferenced by http get
>
>As the p-s discussion I think shows, those have distinctly different
>implications of implementations. Particularly for the last two, is a
>ws-context implementation required to handle both ? Do we actually want
>all this "flexibility" - it looks nice, but in fact it inhibits
>interoperablity and makes it more difficult to get things to work
>together. You can't just mix-and-match, because they won't match.
>
>Of course, a referencing specification can nail things down (as in the
>p-s facility), but then it becomes doubtful how much ref specs that
>choose different options are actually benefitting from the "common"
>base. We don't want ws-context to end up like OSI Session, which was
>pretty much two different protocols munged together in the same
>document, but with different app protocols choosing different
>"functional units" to get back to the session protocol they were
>actually using. No-one benefitted from that - implementors, users, other
>standardisers (not even the techno-politicians who had insisted on it
>originally, as far as I know)
>
>A common base assists implementation if the implementor of a higher spec
>can use the implementation of the lower. But if the lower is full of
>options that doesn't actually help - its quicker to implement the
>specific as part of the higher than make an all-possibilities lower
>first and choose from it.
>
>On the specific, I think we should drop one of the two dereferencing
>mechanisms. I could put this in as an issue, but lets chase it round a
>bit first.
>
>Peter