Re: AW: OCP transport nomination

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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.