Re: BEEP as OCP transport

[Marshall Rose <mrose@xxxxxxxxxxxxxxxx>]

again, speaking as the beep guy, not the co-chair:

> I share this experience in other protocols/areas. There are just to
> many variables to find a good fit between a general-purpose protocol
> library and a decent-size project. This is why I am also concerned
> with XML!
    
all i can say is that your perception about xml appears to be at
variance with my impression of a lot of other people's perceptions.
    
    
> ... if you already use C language, do not have performance or memory
> management problems with expat ways of doing things, and are OK with
> MIT license. This is actually what surprises me about the XML choice
> for BEEP Core -- its use is so limited that it is hard to justify!

see above.

    
> If somebody takes a shortcut in supporting the XML part of BEEP, it
> would be trivial to prove that their implementation is not OCP
> compliant by sending an "interesting" (difficult to parse but valid)
> XML element as a part of a channel management routine.

the xml subset used by beep makes that rather difficult.
    
    
> Thus, we would
> either have to close our eyes on this problem and test with simple XML
> elements only, or we would have to acknowledge that many (most?) OCP
> implementations are not really compliant. Not a nice choice.

i think it's a false choice. anyone who can wade through and understand
the opes specifications, will have no difficulty dealing with xml. let's
keep our perspective here.
    
    
> The same can be said about MIME, I guess. Most HTTP implementations
> fail to parse at least some "interesting" MIME-like headers
> (quotations, escapes, multiple lines via LWS, etc.). This is really
> unfortunate and does lead to compatibility problems long-term.
> 
> What do you think about documenting an even simpler XML subset and
> recommending (requiring?!) its use within OCP/BEEP? Would that help at
> all? Did you consider that option when designing BEEP?

no, because then you move out of the realm of widely-deployed
tools. that's why canonical xml is a bad thing: it requires the use of
special-purpose libraries.

    
    
> > > 	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.).
> 
> Yes, that is why the always-respond restriction in BEEP seems out of
> place. Some applications (like OCP) do not care whether certain OCP
> messages are already being worked on (a pipeline model).

ok, do you care that they actually got there or not?

    
> > 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.
> 
> Do you mean a stream of ANS frames, with optional in-frame aggregation
> of syslog messages? Aggregation aside, that seems like the only sane
> way to do "streaming" or "pipeline" with BEEP. I kept the same
> approach in mind when considering OCP over BEEP. Or are you talking
> about something else?

if you don't need an acknowledgement for each MSG, you can do what
reliable syslog does, wherein the server sends a MSG when the channel
opens, and the client sends back zero or more ANS in response.
    
/mtr