Alex Rousskov wrote:
The above negotiations (automated or via configuration files) are
unavoidable anyway!
A valid question still is whether such negotiations should be built
into OCP or not. I'm not taking either side (yet :), just saying that
pros and cons should be looked at before we start adding more and more
to OCP itself.
For example, one might also imagine that the OCP application to be
used is (implicitely) indicated by the service to be called (and its
description). Meaning, if an OPES processor decides to do a callout in
order to execute Service A, one might assume that the description of
Service A also tells the OPES processor what OCP application to use
(likewise for the callout server). Note, that there might be multiple
'services' with different OCP application bindings defined for one and
the same callout application (e.g. a virus scanner accepting files via
HTTP, SMTP, and plain).
The proposed solution does not make negotiation more complex.
Some kind of negotiation or agreement is required, sure. The question
is whether this mechanism should be build into OCP or if it would be
beneficial to assume this to happen "out-of-band". Just asking for the
pros and cons.
it actually clarifies negotiation purpose. OCP negotiation must result
in an agreement regarding OCP application protocol, which includes the
usual things like name, version, message framing, meta-data (headers),
etc. If you look at it, it all boils down to how to encode/interpret
"meta-data" and how to interpret "data" (what is it I am getting?),
something we have to negotiate anyway if we want to remain application
agnostic. We can probably agree on the same meta-data encoding/format
for all applications. Then,
OCP application protocol == required meta-data fields +
"data" meaning
OPES WG may then publish an "HTTP as an OCP application protocol"
draft where the above things will be specified for HTTP. Other working
groups and individuals may publish their own application protocol
bindings.
Sounds reasonable.
Does the above sound convincing enough? Or do you still think I am
opening a pandora box (that was closed before)?
Not yet sure about the "pandora box" :)
It's fine if we're convinced that this should be built into OCP, and
if we keep the mechanisms in OCP as simple as possible and stay within
our scope.
-Markus