[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fixing "application message" mess


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