generally, I'd hesitate to dismiss or to deviate from an established
standard just to get the protocol syntax closer to something a group
of developers is already familiar with. If an existing protocol fits
our needs, let's take advantage of it and use it the way it is. If it
doesn't really fit our needs, we might be better off defining
something new (rather than trying to tweak an existing approach to our
From the discussions so far, it seems that the functionality and the
features provided by BEEP mostly fit our needs. The main concern seems
to be about XML related performance and implementation overhead. An
option might be to use XML only for BEEP's channel management. Would
this address the performance concerns?
Are there other fundamental issues that would speak against using BEEP
and justify a new protocol (or suggest using another existing protocol)?
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
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
That's basically what I mean. Learning all the good things from BEEP
and reusing as much as possible for OCPTRAN.