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)

["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