Alex Rousskov wrote:
As we discussed before, it is not the amount of work to build OCPTRAN
that pauses us, it is our desire to reuse things defined on top of or
for BEEP Core (such as security negotiations).
And if we don't reuse these things, we've to re-invent them again,
which adds to the amount of work... More important, however, is that
we can rely on established solutions and don't have to worry about
many things, including the security negotiations you mentioned.
The original motivation to build OCP was to provide an application
agnostic protocol (ICAP is HTTP-specific) with several key features
missing from ICAP (e.g., multiple adapted response generation or
copying optimizations). We cannot just "polish" ICAP to get most of
those new things supported; we would have to make major changes, which
is what OCP is supposed to do.
Absolutely, this is the "benefit" I was referring to.
If we do not use BEEP, but still do OCP, we can make messages look
similar to ICAP ones. OCP can be a new protocol (with all the desired
features) that just has ICAP-looking messages. Or, to be more
accurate, messages that look more like ICAP/MIME than like BEEP/XML.
Sure, that's an option, but we would than have to re-define all these
things that something like BEEP already offers.
Please note that I am not casting my vote here, just documenting and
clarifying available options:
- "polish" ICAP (e.g., document encryption) [ call it ICAP/1.1? ]
- write OCP on top of TCP [ call it ICAP/2.0? ]
- write OCP on top of BEEP [ call it OCP/BEEP ]
Understood, it's appreciated! And we need to get closure on that one
to move on. Anyone else a strong opinion?