On Mon, 7 Apr 2003, Markus Hofmann wrote:
Alex Rousskov wrote:
o clarified application message definition and OCP boundaries by
introducing three kinds of "applications": processor input,
processor output, and OCP application
Apology if this has been addressed before, but it seems the term
"OCP application" might be a little bit confusing in this context.
Isn't it the case that it describes that payload type pf the OCP
message, so that we could use "OCP payload type" rather than OCP
application?
I agree that "OCP application" is awkward. However, we are not talking
just about OCP message payload. The term refers to the set of
agreements (a protocol) covering things like:
- meta-data encoding
- required meta-data fields and their meaning
- data encoding
- data meaning
The exact combination is unknown a priory. For example, in some cases,
it may make sense to agree on meta-data and let meta-data describe
data encoding and meaning.
The "other side" of OCP communication does not know what it is getting
in meta-data and data fields. It needs to be told about encoding and
meanings, just like, say, HTTP defines HTTP message encoding and
meaning.
Again, a better term than "OCP application" would be great, but it has
to cover all of the above things. It is the result of OCP agents
negotiations about data and meta-data.
Another important thing is that it should be easy to show that there
is no documented/required relationship among processor input
application, OCP application (or whatever we call it), and processor
output application. When all three are "applications", the
explanations are easy.
Suggestions?
Alex.