Alex,
[...]
Also, one good thing about BEEP messages is that they all have a
known, easily-available size (encoded as an integer value in the first
line of a message). The above looks similar to HTTP and loses the
known-size advantage. The size can be added as a "Content-Length"
header, of course, but you have to parse a lot more to get to that.
Alternatively, we can add size to the first line and lose similarity
with ICAP/HTTP.
I also like the size information.
But BEEP is only a little ahead to today's ICAP/1.0.
The size is for the payload only, you still need to parse frame
header and footer. In ICAP/1.0 there is the chunked transfer encoding
which is a little less but mainly the same.
I think that OCP should extend the usage of size information, if
possible even for OCP meta data.
I think what we need to understand is whether you do not want BEEP
just because it uses XML or because it does not look like ICAP/HTTP.
Once we know the true obstacle, we can try to see how BEEP can be
modified to remove that obstacle.
It's something of both.
First, I assume that a complete OCP on BEEP protocol specification
would define many XML fields like the greeting message as fixed or as
only a small set of possible values.
Only little information could really benifit from XML flexibility.
But a full compatible implementation will nevertheless need a
full featured XML parser as you pointed out earlier.
That looks like a lot of ovehead to me.
I would rather like to get the protocol XML free.
Second, as I wrote before I like to see some migration path for
existing ICAP developers. At least a few syntax elements where we
can say "yes, that looks like a next generation of ICAP".
That's why I proposed to make the session/channel management ICAP
or HTTP like. All other messages could then look much more like
original BEEP messages
For example, it is probably possible to define OCPTRAN as "XML-less"
BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
reusing (redefining without much effort) most of the existing BEEP
work. This approach would be similar to, say, binary XML that exist
for wireless protocols (binary XML gets virtually all the advantages
of XML but uses different representation for various performance
reasons).
That's basically what I mean. Learning all the good things from BEEP
and reusing as much as possible for OCPTRAN.
Martin