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.
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.
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.
> 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.
And stop saying "it can be".
IMHO it CANNOT be a protocol converter if it is not related to the
entry protocol (but the use of different I/O protocol will [affirmative
mode] make it a part of a protocol conversion system).
This will have an impact on OCP. The protocol sequence is then:
http > call-out > smtp.
jfc
Alex.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/03