Re: ANS interleaving (was: Asynchronous BEEP draft status)

On Wed, Nov 26, 2008 at 8:09 PM, Thomson, Martin
<[email protected]> wrote:
> Hi Sam,
>
> You state that ANS interleaving is a useful feature of the protocol, and then point out that almost no-one bothers to implement it.

Implementors are having enough trouble getting basic communication going!

Beepy and beep4j wouldn't communicate at all when we first tried,
beepy had broken SEQ handling, and beep4j had broken MIME header
format parsing, and beepcore-c wouldn't talk to vortex. I haven't
tried the first two against the latter two, yet. Hopefully it will go
well.

> Can you provide a use case?

But those gripes aside, I sure can. Both for an ANS, and just
generally for transferring files larger than should be manipulated
in-memory.

RFC3080: "in a one-to-many exchange,  multiple answers may be
simultaneously in progress"

MSG: <get-all-movies actress="uma thurman">

ANS: a movie, type and name defined in MIME headers, with Uma Thurman in it
...

The MSG would kick into gear a heavy duty search of known movie
download sites, and each ANS would be a single movie, sent as it is
found in small chunks (movies are big!), possibly multiple ones would
be found at once and sent.

Anyhow, like async channels, its a feature that you can do without,
you can build it on top of smaller message exchanges tied together by
identifiers that are not BEEP message numbers.

For example, we transfer large dynamically generated PDFs over BEEP.
With beepcore-c, as data is ready we would write out a frame of a RPY
(which might get further subdivided as needed to fit window size), but
instead we RPY with a "its coming at you soon with this message-id",
and then send each chunk of data as it is available with a MSG (which
gets an empty RPY).

Mind you, we reply before we actually process the request to generate
and send the file.

Actually, we have a "thin" UI client (beep4j) that uses BEEP to talk
to its server (heavily modified beepy), and almost everything that
happens on the client involves a MSG being sent to the server,
followed by an immediate RPY <ok/>, and then the server starts doing
whatever processing is required for the requested action.

Would you really consider our use of BEEP a massive conformance breach
of an RFC3080 "process before sending RPY" restriction on the
implementation of profiles?

Cheers,
Sam