Re: Asynchronous BEEP draft status

On Wed, Nov 26, 2008 at 3:21 PM, Thomson, Martin
<[email protected]> wrote:
> Sam:
>> Note that Vortex delivers each MSG on a seperate thread, exactly as
>> described above.
>
> If this is the case, then this is directly against the stated requirement in RFC 3080, Section 2.6.1:
>
>   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.

This is far-fetched.

Vortex is acting correctly. It delivers the MSGs to the API serially
(to different threads).

BEEP places no requirements on the what "process" means for a profile.

[reordered]
> Sam:
>> BEEP msgnos are ordered across a channel, of course, but application
>> msgs can be replied whenever you want.
>
> This is in direct contravention of the quoted requirement, above.

BEEP RPYs are passing over the wire in the RFC defined order.

I could write the code in the other toolkits I use, too (beepy,
swirl/beepcore-c, and beep4j).

> Of course, to operate in this mode, a client will have to implement a demux layer that redirects responses to the entity that originated the request.  Without this layer, the BEEP stack would redirect responses to the wrong entity.
> In your example, the entity that makes request 3 would receive response 5 instead.  This is less of a problem in C, but much more of a problem for an OO language implementation, c.f. beep4j.
> You've made a conscious decision to move the complexity to the application.

Yes, where it belongs.

Demonstrably trivial complexity (implementable in a few lines of C
code in my example, I don't believe its harder with beep4j, we use it,
its a good toolkit).

The complexity of the code that implements application functionality
will dwarf these few lines.

This is what BEEP is designed for, to be a protocol to build
protocols, not a finished thing implementing everything you could
want.

> Sam:
>> c - BEEP adoption suffers from non-interoperability of existing toolkits.
>
> Feature negotiation ensures that this option cannot be used without agreement.  I can't see how this work affects interoperability.

Some toolkits will have it, some won't. Profiles specified as needing
the extension will be implementable with some toolkits, not with
others.

Cheers,
Sam