On Wed, 16 Apr 2003, The Purple Streak, Hilarie Orman wrote:
OPES is not going to do protocol conversion. An OPES-like
architecture could, at some point, define the processing points and
control messages for this kind of functionality, and I hope that
someday we'll get there, but I doubt that it will be in a WG called
OPES.
I think you gave a premature answer. If OPES is to support HTTP, then
OPES processors will have to participate in protocol conversion (HTTP
-> FTP) because an HTTP proxy has to do that. In fact, any existing
HTTP proxy that supports ftp:// URLs is, essentially, an OPES
processor. It adapts application messages that it proxies! Have you
ever thought about what happens when your browser sends
GET ftp://ftp.example.com/pub HTTP/1.0
through an HTTP proxy? ftp.example.com does not talk HTTP on port 21
and does not know about HTML. Yet, your browser gets an HTTP response
with a nicely formated directory listing in HTML. Magic?
Note that I am not saying that OCP has to be involved.
You make a good point in observing that if OPES did protocol
conversion, then the notion that the callout protocol is the encoded
in the proxied protocol becomes confused - callout transactions
would logically use protocol X in one direction and protocol Y in
the other. And further, we'd have to think through several issues
about matching names, authentication methods, connection initiation
to endpoints, etc. that just didn't come up when we did the
architecture.
I think you are finding complications when none exist. At least not at
the OCP Core level. Look at the way application message is currently
defined in OCP Core. There is no place for [additional] confusion,
even if protocol conversion is done via callout servers. The [proxied
protocol (or protocols) do not exist at the OCP Core level!
Of course, someone might be able to do some protocol conversions
using OPES and a single protocol encoding for the callout protocol.
That's fine and good, I'm sure the framework we are developing will
support more uses than we directly address.
True.
Alex.