On Tue, 22 Apr 2003, Markus Hofmann wrote:
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
Yes, of course, though the OCP requirements draft may not apply in
this case because it defines many requirements that have nothing to do
with OPES framework but simply outline what we think a _good_ OCP
protocol can be. In other words, it is possible to build an
OPES-compliant system using a non-OCP-compliant callout protocol.
(which might be obvious if "other than OCP" is a local procedure
call on the OPES processor).
As I probably mentioned before, the architecture documents do not
(cannot?) distinguish "local" from "remote" without severely limiting
OPES processor definition. The processor "box" is not well defined,
and even "local" adapters have to obey applicable OPES requirements
(if any).
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 agree. All I am saying is that OPES framework requirements such as
tracing and bypassing draft(s) should not have any dependency on a
particular form of the callout/adaptation mechanism. This is the
primary reason to keep those drafts specific to OPES processor (or
even dispatcher, something we would have to argue about later).
I believe we're basically in agreement here.
Yes, I think so. We can proceed without violating each other
preferences, at least for now :-). We may have to revisit the "local"
versus "remote" and "processor" versus "dispatcher" issues later, when
it is time to define OPES tracing/bypass scope. At that time, I will
argue that, for example, it is impossible to bypass non-OCP adaptation
"inside" the OPES processor as it is currently defined, and I would
argue that the definition or usage of "processor" and "dispatcher"
terms should be revised to allow for such bypass and to erase any
distinction between OCP-based and other adaptors.
Thank you,
Alex.