[BXXPwg] Design decisions

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Thu, 6 Jul 2000 16:08:29 -0700


hi. i imagine there are quite a few similarties between the designs, though
i'm not sure why it wasn't pursued.

with respect to the differences:

1. syntaxes and error tokens: these are probably more matters of taste than
anything else.

had i been working on bxxp 10 years ago, i probably would have favored
either 822 or ASN.1. right now, the software vectors for XML are pretty
strong, so that makes it a reasonable bet for longevity.

the three-digit camp moved to a more extensible format in SMTP a few years
back. i tend to prefer the digits since using "code 250" in a conversation
is considerably less ambiguous than using real words...

2. multiplexing:

i think the acap/imap approach works when you really aren't planning on
using multiplexing much. if you're trying to encourage its use, then the
rules they have are just a little too fast and loose. the bxxp model is to
encourage extensive use of multiplexing, so we had to be less casual.

i think that if you're doing something like this:

    open some channels for tuning
    open a channel for data exchange

then the flow control stuff is overkill. however, when you start having
multiple channels active simultaneously, you need some kind of flow control
or you will deadlock and you'll see this in the field.

the design decision was that it was worth it to burden small implementations
in order to having to go through a big negotiation as to what both sides
were going to do...

in other words, if you're writing an API for a client-side application, and
you know that you're behavior is going to be pretty simple (like the
sequence above), it's pretty trivial to hardwire when the SEQs get sent and
what the values are. if you're writing a general purpose API and you want to
support all kinds of different interaction modes, then you're going to do
more work. this follows the "more pain, more gain" maxim...

/mtr