[ speaking as the beep guy...]
For example, it is probably possible to define OCPTRAN as "XML-less"
BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
reusing (redefining without much effort) most of the existing BEEP
work. This approach would be similar to, say, binary XML that exist
for wireless protocols (binary XML gets virtually all the advantages
of XML but uses different representation for various performance
reasons).
That's basically what I mean. Learning all the good things from BEEP
and reusing as much as possible for OCPTRAN.
unfortunately, you've taken exactly the wrong lesson here.
if you're trying to do beep-like things, you should use beep. because,
frankly, this group isn't going to be able to make better decision
decisions than the group that did beep. quite the reverse.
obviously, if there are parts of beep that you don't like, then:
- if they're optional, then don't use them.
- if they're not optional, then you're not trying to do beep-like things.
and if the answer is the latter, then go off in another direction, and
that's just fine.
if your concern with beep boils down to the xml, then don't use xml in
the channel definition for ocp... use something else. (yes, you'll
still have to use xml for beep's channel management, but that's very
constrained, and i guarantee you that you have much harder problems to
deal with than trying to optimize channel management in beep.
/mtr