as requested by alex, i'll reply.
speaking as the beep guy, instead of the co-chair:
1. BEEP exists but is new
BEEP Core specification is a stable "Standards Track" RFC.
However, only few protocols over BEEP have been documented
and, as far as I can tell, none are super popular yet.
This means that we do not need to reinvent the wheel, but
we may also find yet-unknown problems with the existing
wheel design.
i think your greater risk in terms of whether you can find a library you
like or whether you have to role your own.
experience with reliable syslog shows that the libraries out there are
"too general" for what syslog implementors want. unfortunately, those
implementors found that out the hard way, i.e., they invested a lot if
using a library instead of just rolling their own implementation.
further, some of the non-commercial libraries out there are GPL'd, which
many open-source and commercial implementors reject because of the
down-stream constraints it places on their code. (it was a bit of an
eye-opener to hear that even the open-source guys think this way.)
the choice of whether you use a library or roll-your-own all comes down
to "cost", which includes things like price (free or not), but also
includes things like the integration cost (e.g., same language, same
threading model, required libraries, etc.)
certainly many of the reliable syslog implementors i've talked to feel
they would have been better served by rolling their own...
2. BEEP uses XML
xml is mandatory in beep for channel management, that's it. the subset
that of xml that beep uses means that you can take something like expat
and easily integrate it.
for an ocp channel, you can use any format you want. beep doesn't
care. it gives you an 8-bit clean container. after that, it's up to you.
3. BEEP is connection oriented
the only protocol i've ever seen that had a reason for being both CO and
CL is the DNS, and even then, the kind of transactions being used by the
DNS for CO and CL vary dramatically.
if it makes sense to use ocp in a CL mode, don't consider beep. do
something else.
4. BEEP exchange styles are close fit, but not perfect
BEEP requires replies to every BEEP MSG. OCP does not.
We can add "null" replies, of course, but the
protocol does not need them (it would be a waste from
technical point of view).
Some might argue that mandatory replies will actually
make OCP easier to understand.
the reason why MSG's get a response is because until you see the
response, you never know if the the MSG actually got to the other side
and got worked on. ultimately, it's the application, and not the
transport, that's responsible for things like that (cf., Clark, etc.).
if you want to do some kind of streaming thing in OCP, you can look at
the way syslog reliable does it. darren came up with that and it's
fairly elegant.
I wonder why BEEP assumes that replies must be required
(being so flexible in other aspects), but it is
probably too late to change that assumption. Can BEEP
exchange styles be extended? Probably not without
losing compatibility with existing BEEP libraries.
you'd need to define a beep feature negotiation to do that.
5. BEEP Core does not determine transport
We would still have to decide whether OCP runs
on top of BEEP/TCP only or allow other BEEP
transport bindings.
realistically, does something besides TCP have any significant presence?
6. BEEP Core does not determine encoding
We would still have to decide how to encode OCP
messages. BEEP defaults to application/beep+xml,
but other MIME types can be used.
true. see my answer to (2) above.
7. BEEP channels allow simple low-overhead OCP connections
i'm not sure what this means. if you take a look at the xmlconf stuff,
they have a specialized application which requires multiple parallel
running in the same authentication context. they use beep for that.
even if you don't have the multiplicity requirement, using beep means
you never have to screw around defining authentication/privacy stuff,
because beep comes with sasl and/or tls.
if you find yourself defining a protocol that has a lot of
administrative overhead (e.g., negotiation, security, etc.), then odds
are you should have looked at beep before specifying all that stuff.
however, you should always use the best tool for the job. if beep is
overkill, don't use it.
/mtr