Re: Asynchrony and BEEP

Hi Martin,

Assuming the set of details you provided, I think you are facing a
problem which is simple to solve using features already provided by
BEEP. Here is how:

- Create two channels, one to push jobs and one to receive jobs
finished. 

- The channel to push jobs use a MSG/RPY pattern. Once the listener
receive a job request (MSG), it is queued/handled as desired, but before
doing that, a RPY must be sent to acknowledge MSG reception.

- The channel that receive jobs finished issue an initial MSG to open
the possibility to receive ANS replies that carries jobs finished. Now,
each time the listener have a job finished he send it back as an ANS
reply to the MSG received on this channel. This will allow to send in
any order jobs as quickly as they are finished.

Now, I would like to comment some assertions you have done:

1) (Please see 3.4 and 4.1 of [1]) The technical reason to make
intra-channel processing to be serial is because it is the most widely
available request/response model in use today. Thus, it is required to
be represented in BEEP, mainly because people use it. You say it is used
in some cases (????) but it is by far the most popular model used in
connection oriented escenarios (like HTTP). 

However, what makes BEEP different, is that channel pipeline is *not*
the only one invocation model. You can use several channels or use
ANS/NUL replies semantic to implement independent exchanges.

Channel pipeline is a *core* BEEP feature, well understood and well
perceived by people using BEEP. What you are proposing is a protocol
change that have also consequences in what also makes BEEP different and
useful: how it is handled session close.

2) Saying channels suffer "head-of-line" is quite inexact. I believe a
protocol can suffer "head-of-line" when there is no alternative (like
HTTP). BEEP channels have several already available and well supported
invocation options to specifically avoid "head-of-line". 

3) Maybe this could change in the future, but at this moment, features
and profiles can only extend BEEP function giving semantic but never to
modify base BEEP protocol defined at RFC3080 (maybe I'm wrong but I
believe this is the essence).

4) Message number is not only used for protocol errors, but also to give
the notion of unique and identificable transaction (which is, again,
commonly required), and to allow APIs to reply to a particular message. 

Cheers,

[1] http://www.rfc-editor.org/rfc/rfc3117.txt
-- 
Francis Brosnan Blazquez <[email protected]>
Advanced Software Production Line, S.L.