Alex Rousskov wrote:
OPES architecture already assumes that adaptation can be done by means
other than OCP.
Only if this "other than OCP" fully complies with the requirements
outlined in the WG documents (which might be obvious if "other than
OCP" is a local procedure call on the OPES processor).
If this "othern than OCP" would have to be modified/extended in oder
to meet the requirements, or if the usage of "other than OCP" would
imply additional complexity on the OPES framework, the WG shouldn't
spend cycles on it.
I believe we're basically in agreement here.
Thus, we are not increasing complexity or adding
anything really new. We are simply making a statement that OPES
framework (tracing, bypass, and such) should not depend on OCP because
OCP is not the only allowed way to do adaptation!
See above.
The fact that SOAP may be used as a callout protocol is just a
side-effect of the above statement. We will not focus on SOAP. We will
focus on "our" OCP. "How to use SOAP as an OPES callout protocol"
draft may (should??) end up having a single normative sentence:
use "as is"
Does this approach work for you?
I hope the above provides an answer to that.
If the WG decides that SOAP (or some modification of SOAP) should be
the OCP, the WG will work on it.
If the WG decides that something different than SOAP should become the
OCP, the *WG* should not spend any cycles on SOAP (this includes
possible modifications/extensions to SOAP, as well as requirements
that might be imposed by SOAP on the OPES framework). Of course, this
is *not* meant to prevent individual contributors to look at it, the
WG just won't take this on as work item, and it should not distract
the WG. And, obviously, if SOAP can be used without any
modifications/extensions and without having any additional
requirements on the OPES framework - hey, there's nothing to do and we
also don't have a problem.
If I understood you correctly, that's very much what you said.
-Markus