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