Re: Channel response serialization

> Weeeelllll. If I understand correctly (a big if at this point). You still
> don't have that guarantee because all you are specifying is that replies
> have to be sent in the same order that requests are received. Nothing is
> stated about the order in which requests have to be processed. 

It's not as clear as I'd like, but Section 2.6.1 of RFC 3080 says:

   A BEEP peer acting in the server role must process all "MSG"
   messages for a given channel in the same order as they are
   received.

I suppose this could be taken to mean that the BEEP layer, and
not necessarily the application, need do so, but I don't like
that interpretation.

> In fact to paraphrase an earlier reponse in this thread: the library
> actually holds responses until all repsonses to eariler requests
> have been sent. This implicitly allows you to give responses to the
> library out-of-order.

BEEPCore-C does this.  This moves the responsibility for adhering to
S2.6.1 to the application.  We chose not to do this in PermaBEEP to
protect developer toes.

> Anyway, yes you can point me at the right parts of code. I'm a Java
> programmer by preference. Of course, I might come to the same
> conclusions as y'all.

To remove the restriction on delivery of MSGs to the application, I
think it should just be a matter of removing a check in
Channel.getMessage() (and perhaps cleaning up assorted unneeded
notifications.)  How do provide out of order RPYs (non-interleaved)
actually requires a bit more thought from me, but all of the relevant
modifications for everything we've discussed would be to Channel.java.

> By the way, why isn't PermaBEEP listed at beepcore.org?

It's listed under Products, not Projects.  I suppose I should create a
duplicate entry, but embarassingly I've forgotten my beepcore login
password.  Who's in charge of the site these days?

--Jered