Joseph Hui wrote:
That said, I also believe, in consideration of security and privacy,
it'd be prudent to also require that the transitivity of trust
along a CSC be controllable to some reasonable extent by the CSC caller.
Do I understand you correctly that this would require the OPES
processor to specify the callout server chain, i.e. the OPES processor
decides which servers are in the chain and how they're chained? If I'm
not mistaken, this would be different from Hilarie's viewpoint, where
"... the first service processor can plan the processing pathway...".
I'm using the "to some reasonable extent" phrase, because in
reality this will present a great challenge to the callout
protocol designers.
You seem to assume that this will have quite some impact on the
protocol, while Hilarie's viewpoint is that one additional header
would be enough. Can we somehow examine why we come to such different
views?
The value and usefulness of pipelined
processing can be trivially demonstrated, using a
Unix command line as an example, say, A|B|C. That's
a positive.
Well, if A, B, and C are servers, and the communication cost from the
OPES processor to each of the servers is minimal, than chaining
doesn't buy me too much - it might even be worse, e.g. if
communication cost between the servers is higher than between the OPES
processor and the servers. So, it strongly depends on the deployment
scenario - and I was wondering what a typical OPES deployment scenario
would be in which chaining would either be beneficial or a
disadvantage - I can see both, and I'm just wondering whether the
expected benefits in those specific scenarios would justify possible
added complexity.
-Markus