On Thu, 17 Apr 2003, Marshall Rose wrote:
1. BEEP exists but is new
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...
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!
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.
... 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!
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. 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.
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?
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.
Yes; I should have stated that in the original summary.
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.
I should have said "BEEP is a lossless protocol". However, your DNS
comment is important. Let's wait for Hilarie to drive that lossy
transport argument.
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).
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?
I would not recommend using aggregation trick with OCP though.
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.
Interesting point!
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?
No, unless Hilarie manages to convince the group that lossy transports
such as UDP must be supported (which would create its own problems
because BEEP cannot run on top of UDP as-is).
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.
I agree. #7 is a "for BEEP" argument. BEEP channels are a perfect
match for what OCP connections are. OCP connections are not really
"connections" from transport point of view; more like sessions. Most
OCP negotiations can be done on BEEP session basis (TCP connection),
allowing for low-overhead OCP connections (BEEP channels).
however, you should always use the best tool for the job. if beep is
overkill, don't use it.
Thanks for a detailed response!
Alex.