On Fri, 9 May 2003, Alex Rousskov wrote in "RE: AW: Using XML in OCP transport":
I hope my answers will help you to finalize/voice your preferences.
Yes, thank you very much, Alex.
This is my vote:
Reasons are a mix from all what I said and heard in this discussion so far.
Though I have my preferences: whatever we agree on from these three, I will
help working on the protocol.
Von: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Gesendet: Fr 09.05.2003 19:59
Betreff: OCP transport vote, commitment
At the beginning of this discussion, my vote would have been:
My current vote is:
I would be willing to lead OCP/OCPTRAN development and probably can
have the first draft ready in 2 weeks or so. I would be willing to
lead OCP/BEEP development as well, provided BEEP experts such as
Marshall contribute a lot; I would expect first OCP/BEEP draft to be
available in a month or so. Finally, I would be happy to help with
ICAP/1.1 work, but I think ICAP experts such as Martin should lead
Here is some justification of my current views.
* BEEP versus OCPTRAN: There are two issues for me here. Wheels reuse
and XML scare. Initially, I thought that we should just go ahead
and reuse BEEP. Reuse is great. However, as the discussion got
more specific, I realized that there are two kinds of reuse.
Let me call them black box reuse and white box reuse.
Black box reuse is simple: you take existing something (protocol,
library, whatever) and build on top of it using published
interfaces. There is a clear boundary between the "reused" entity
and its new "owner". In many cases, you can use or invent another
something that can be reused instead, without modifying the
owner much. Examples of black box reuse are: writing a C program
(reusing C language and libc library), wget (reusing HTTP), reliable
syslog (reusing BEEP)
White box reuse is integration/merging with existing something
(protocol, library, whatever) based on the knowledge of internal
structure of that something. The boundary becomes less clear.
In many cases, it is impossible to change the "reused" entity
without also causing significant changes in its "owner". Examples
of white box reuse: writing a Perl program using internal Perl
datastructures for optimization purposes (reusing existing
Perl datastructures), HTTP/1.1 (reusing HTTP/1.0), any protocol
that defines its own BEEP message types (reusing BEEP)
Black box reuse is great. White box reuse often, but not always,
leads to long-term inefficiencies and wasted energy. "Clone and
modify" is often better than white white box reuse, IMO. For
example, I believe HTTP/1.1 folks made a strategic mistake by making
HTTP/1.1 "semi-backword compatible" with HTTP/1.0 (and even having
two conflicting RFCs for HTTP/1.1 itself!). It looks like ICAP
suffered the same problem when migration from ICAP/0.9 to ICAP/1.0
led to major ICAP vendors going different ways while offering
relatively few advantages to justify the loss.
In our case, OCP transport is border-line. We can, of course,
use BEEP as a black box. The resulting protocol will be somewhat
awkward to document and understand, but it will work (black box
approach). We can also add our own message types to BEEP, yielding
a more elegant design, but losing compatibility with existing
BEEP libraries while still having to leave with certain BEEP
features that cannot be simply "extended" (white box approach).
BEEP folks say they saved the world by building something many
working groups will reuse instead of writing specs from scratch. I
agree. Unfortunately, BEEP is not universal enough (nothing
is) -- it makes choices regarding message exchange patterns and
channel negotiations that are not perfect for OCP. It requires XML.
If we proceed with OCPTRAN path, we can (but do not have to) try to
make a similar (but smaller scale) contribution -- future working
groups might be able to reuse our protocol when what they do is more
similar to OCP than to BEEP (efficient asynchronous bidirectional
exchange of large number of opaque application messages that may be
very small or very large). But that's probably too much to hope for.
* XML scare:
Many people worry about XML in an "efficient communication" context.
Perhaps my circle of life is too biased or too small, but that is my
observation. To maximize OCP adoption chances (by ICAP community),
we SHOULD NOT use XML (all other factors being the same, which they
are not). We MUST NOT use XML for each application message exchange;
using XML for connection-related negotiations MAY be OK, if we
really need that kind of flexibility.
Why do I care about ICAP community? Because if those folks do not
migrate to OCP, OCP will probably die, and all our efforts will
Since we are so unsure about OCP transport, and since some belive
that work minimization must be our top priority, polishing an
existing and working protocol may be worse talking about. If we
adopt ICAP/1.0 almost "as is" we can concentrate on other OPES
aspects and, perhaps, make them slightly better.
Migration for ICAP community will be simplified as well, especially
if we make ICAP/1.1 100% backword compatible to ICAP/1.0.
This mail has been scanned by wwsmtp.webwasher.com
(WebWasher 4.4 beta Build 499)