-- was "Subject: OCP questions"
jfc,
You keep mixing OCP and OPES which makes it very awkward (for
me) to respond. The "OCP questions" thread you responded to was about
OCP. OCP Core is application-agnostic and, hence does not care much
about proxied protocols, their conversions, etc.
I took the liberty of renaming your Subject line. If you want
to polish or completely change OPES definition, PLEASE stay on this
new thread and make specific suggestions here. If you want to discuss
OCP Core draft instead, please use existing OPES architecture and the
old thread (or start a new one). I understand that OCP depends on OPES
architecture, but OCP thread is not about OPES in general, it is about
OCP. This new thread can be about what OPES is or should be.
Specific OPES-related comments are inlined.
On Wed, 16 Apr 2003, jfcm wrote:
At 15:22 16/04/03, Alex Rousskov wrote:
On Wed, 16 Apr 2003, jfcm wrote:
Most of the points risen here would get a clear response with a
simple diagrams such as :
http | data input | dispatcher | call-out protocol | server | call-out
protocol | data-output | http
<------ OPES ?
<------ OPES ?
> <--- OPES ?
We already have/had such diagrams. Obviously, they did not provide
enough "clear responses".
hmmm... This is your opinion which translates into some's difficulty
to understand where we are.
What I said is not an opinion. It is a fact. We had very similar
diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in
version head_sid3 of the OCP Core draft [1]) and, since people keep
asking questions, they did not get us "clear responses" you promise.
[1]
http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment
If OPES is defined as the first possbility, http is part of it and
call-out may take it into account. If it is defined the second way,
external protocols are no part of OPES but OCP can consider knowing
it. If it is the third definition (that I thought you would add by
yourself in your response to illustrate the difficulty), then the
call-out protocol has NO relation with the entry protocol.
I do not know what "possibilities" you are talking about. Are they
related to the arrows on your diagram? Care to define them explicitly?
Note that OCP has nothing to do with "http |
data input |" and "data-output | http" parts. OCP Core has specific
wording about that. That wording replaced some of the figures that had
those parts in earlier OCP Core versions.
Seems that this wording does not prevent questions. May be both
could be kept? We could check they fit the different understandings.
By "both", do you mean the old figure and the new wording?
PS. What about protocol conversion, is that OPES?
It can be. An application proxy that does protocol conversion may
support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy
today has to convert between HTTP and FTP (or even Gopher, WAIS,
etc.). I do not see why OPES proxies should be more limited than
existing HTTP proxies. If OCP is involved in protocol conversion, OCP
agents would have to negotiate/agree on how to specify
original/adapted protocols via application message metadata.
At a given stage one must start saying what an OPES is and is not.
OPES is about many specific things. If you keep asking specific
questions ("Is OPES about Foo"), you will keep getting specific
answers ("OPES can be about Foo", but it can also be about "Bar").
And stop saying "it can be".
I was just answering your question! OPES, regardless of the
definition, can be many things. It is OK to say "OPES is about
protocol conversion", but since OPES is also about other things, it is
more accurate to say (IMO) that "OPES can be about protocol
conversion". That is, "protocol conversion" is within OPES scope.
The latter is the best wording, I guess.
IMHO it CANNOT be a protocol converter if it is not related to the
entry protocol
OPES _is_ related to the input/entry protocol. We even plan
input/output protocol-specific drafts, possibly one per proxied
protocol!
(but the use of different I/O protocol will
[affirmative mode] make it a part of a protocol conversion system).
Do not know what you mean by "I/O protocol".
This will have an impact on OCP. The protocol sequence is then:
http > call-out > smtp.
The above is not how callout protocol is now defined. Callout is
something that comes back:
(http) <--> OPES processor <--> (ftp)
^
|
V
(callout)
Alex.