Re: BEEP as OCP transport

[Marshall Rose <mrose@xxxxxxxxxxxxxxxx>]

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