Re: Channel response serialization

> It struck me that that wasn't really the purpose of channels. I got the
> impression that channels were intended to have a semantic purpose - and
> that's how I would like to use them, e.g. channel 0 is a control channel -
> you wouldn't allocate multiple control channels arbitrarily to get around
> the serialization restriction otherwise how would BEEP know that they were
> control messages?

Hm.  I defer to Marshall on any statements regarding intent, but I
think that semantic binding is only one of the purposes of channels.
While the binding of some specific profile to each channel provides
semantic separation between channels, the serialization of messages on
a single channel allows the client to pipeline requests with a
guaranteed execution ordering.

In fact, this is how we make use of multiple channels when performing
complex tasks in our protocols.  We manage a pool of channels bound to
a given profile, and then assign messages to 'free' channels
(i.e. ones with no currently outstanding message), while honouring
data dependencies by pipelining requests on a single channel.

While I don't fundamentally object to the idea of allowing
out-of-order replies on a channel, I don't want to lose the guarantee
of in-order processing of subsequent messages on a single channel.  I
posit that in any protocol that allows for volatile data, there are
few situations in which one is likely to have in-order processing with
out-of-order replies (while maintaining correctness).

Question: If we remove the restriction on reply-ordering, do we then
also allow frames on multiple RPYs or ERRs to be interleaved?  That
seems like the logical next step.  Of course, then for parallelism we
really ought to allow frames of MSGs to be interleaved.  But, then
we're back to something that looks like the channel mechanism, though
less explicitly managed!

> Finally the restriction on reply ordering seems to be arbitrary and forces
> people like me to put in a lot of extra work that we wouldn't have to do if
> the restriction wasn't there (I know, we all want something for nothing
> :-) ).

PermaBEEP goes a step further towards enforcing this by not allowing
the application to retrieve the next message on a channel until it has
initiated a reply to the last message delivered to the application.
(Note that is initiated, not fully sent.)  This decision was a bit
contentious, but I think it best serves developers in that it prevents
them from shooting themselves in the foot in a system that dispatches
requests into a server framework.

If you think it would be interesting to explore, I believe it would be
relatively easy to modify PermaBEEP to remove both this and the
restriction on reply ordering.  I'm not sure there's a lot of value in
it, though.  (Hm, and I really must roll the 0.9 release soon; I meant
to do that last month.)

--Jered