well, as the resident beep guy, i guess i get to comment. however,
rather than answer your questions directly, i'm going to state a general
principle and then let you apply it to your situation.
the principle is this:
there is nothing stopping anyone from writing their own limited beep
stack that integrates exactly with their application exactly the way
they want it to.
people who write generalized stacks have a set of constraints that are
probably inconsistent with what you're interested in. that's fine, we
don't have to have a one size fits all model.
beep is designed in such a way that you basically pay for what you
use. if you know before hand that you're going to have at most two
channels open (channel zero for management, and another channel for data
exchange), then you can write the transport mapping stuff in one screen
of C (maybe two pages if you like comments). (hint: when the peer asks
to start another channel, send back an <error/>).
in fact, the "just say no" thing works great for most of beep's
features. what you're left with is a mandatory framing mechanism and
some xml parsing for channel 0.
if you want your beep stack to support a threading model, great; if not,
then don't. it's up to you.
here's an interesting thought experiment: list all the requirements that
the community has for the-next-syslog, e.g.,
> - reliable transport via TCP
> - a much larger allowed message size than 1024 characters
> - support for non-western characters
> - some more meta data (like the full-blown timestamp, but this might go
> into the content area and as such might be outside the charter of this
> WG. I am still mentioning it so at least some header changes can be
> considered)
> - maybe hooks for optional encryption and authenticy - but this might go
> too far
> - most importantly is easy to implement and does rely on right now
> readily available libraries, which unfortunately means sockets, only...
is a good start (although the liklihood that the security guys will let
you avoid requirements for authenticity, integrity, and privacy are nil).
anyway, when you compile the final list and then start the design work,
i think it likely that what you have will be at least as complex, and
probably more complex than beep. why? because the secret of beep is that
it's nothing more than a tight integration to a number of proven
solutions to doing applications stuff. the integration part is new, the
rest of it isn't.
now, the parts of your requirements that don't deal with protocol
exchanges (e.g., i18n) are interesting, and i think that may be an
interesting thing for the wg to get into, assuming the ADs are
interested in extending the charter, and depending on your reasoning,
they may very well be...
/mtr
