Sequential processing of frames

Lionel Cons

unread,

Sep 24, 2012, 9:40:16 AM9/24/12

to stomp...@googlegroups.com

We are left with only two open issues for STOMP 1.2 ([1] [2]) and both are
related to the sequential processing of frames. This has been discussed
already on this list (see the mail threads linked from the two open issues)
but I'm afraid we haven't reached any consensus.

On the client side, it would be much better to guarantee that frames are
processed in order to ease coding. OTOH, on the server side, it gives more
flexibility if sequential processing is not required. A more advanced
mechanism allowing clients and servers to re-sync efficiently is probably a
too big change for STOMP 1.2.

Therefore, I propose to postpone these two issues for a later version of
STOMP and only include in STOMP 1.2 a clarification similar to:

| A `RECEIPT` frame is an acknowledgment that the corresponding client
| frame has been _processed_ by the server. Since STOMP is stream based,
| the receipt is also a cumulative acknowledgment that all the previous
| frames have been _received_ by the server. However, these previous
| frames may not yet be fully _processed_. If the client disconnects,
| previously received frames SHOULD continue to get processed by the
| server.

Unless someone disagrees or proposes a better text, this is what I plan to
include in STOMP 1.2.

Cheers,

Lionel

[1] https://github.com/stomp/stomp-spec/issues/9
[2] https://github.com/stomp/stomp-spec/issues/47