On Mon, 5 May 2003, Martin Stecher wrote:
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.
Good point.
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 agree. The ideal protocol should make it easy and efficient to
"skip" or "extract" complete OCP messages without much parsing.
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.
The worst case scenario :-).
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
Comparing the above to reasons/arguments, it seems to me that the
second is of much lesser importance. The second argument is less
technical and more of a gamble: ICAP developers can be turned off by
even small changes to the existing protocol (NetApp and Akamai are
examples of how [ICAP/1.0] changes [compared to ICAP/0.9] alienated a
part of the protocol community, I guess). On the other hand, most
developers are probably proficient enough to handle whatever protocol
we come up with, from scratch.
Even if you disagree with the above comparison, I would still suggest
that we try to agree on the XML issue first and resolve the "ICAP
path" disagreements (if any) later. More on this in an XML-dedicated
message that follows.
Thanks,
Alex.