STOMP 1.2 Draft Specification

[Lionel Cons]

In the past weeks, I've tried to collect all the "minor" problems identified
with STOMP 1.1, create issues in GitHub [1] for them, discuss the relevant
topics on this mailing list and edit the draft 1.2 specification [2] to record
our consensus.

There are still a few open issues but most of the work is done and I consider
the current 1.2 draft as (hopefully) close to final.

Could you please carefully review this draft [2] and send feedback on this
mailing list?

Cheers,

Lionel

[1] https://github.com/stomp/stomp-spec/issues
[2] https://github.com/stomp/stomp-spec/blob/master/src/stomp-specification-1.2.md

[Hiram Chirino]

For easier consumption I've rendered the markdown to HTML which you can access at:

http://stomp.github.com/stomp-specification-1.2.html

--

Hiram Chirino

Software Fellow | FuseSource Corp.

chi...@fusesource.com | fusesource.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo

[Chris Barrow]

Hi Lionel, all,

Thanks for your great work on this spec. Here are some comments.

CONNECT or STOMP frame

Clients that use the STOMP frame instead of the CONNECT frame will only be able to connect to STOMP 1.2 servers

This is incorrect, they can also connect to STOMP 1.1 servers.

MESSAGE frame
The new ack header is now mandatory:

"If the message is received from a subscription that requires explicit acknowledgment (either client or client-individual mode) then the MESSAGE frame MUST also contain an ack header with an arbitrary value. This header will be used to relate the message to a subsequent ACK or NACK frame."

How about avoiding this backwards incompatible change by instead making the ack header optional, and stipulating that the client must use the message-id as the ACK id if the ack header is absent? The above quoted passage would be reworded as follows:

"If the message is received from a subscription that requires explicit acknowledgment (either client or client-individual mode) then the MESSAGE frame MAY also contain an ack header with an arbitrary value. This header, if present, MUST be used to relate the message to a subsequent ACK or NACK frame. Otherwise the message-id header is used."

There two motives here: (a) avoids forcing a change for STOMP servers (clients would still need to be changed to respect the ack header if present) (b) avoids unnecessary duplication and bandwidth usage in cases where the server wants the message-id to be used as the ACK id.

BEGIN
I don't find the following sentence very clear:

Transaction identifiers MUST be unique per connection.

If the intention is to say that transaction identifiers must be unique within the same connection, then I would suggest mirroring the language used for the SUBSCRIBE id (which I do find it very clear), i.e.:

Within the same connection, different transactions MUST use different transaction identifiers.

thanks,
Chris

[Hiram Chirino]

On Fri, Sep 14, 2012 at 12:53 PM, Chris Barrow <chris....@kaazing.com> wrote:

MESSAGE frame
The new ack header is now mandatory:

"If the message is received from a subscription that requires explicit acknowledgment (either client or client-individual mode) then the MESSAGE frame MUST also contain an ack header with an arbitrary value. This header will be used to relate the message to a subsequent ACK or NACK frame."

How about avoiding this backwards incompatible change by instead making the ack header optional, and stipulating that the client must use the message-id as the ACK id if the ack header is absent? The above quoted passage would be reworded as follows:

"If the message is received from a subscription that requires explicit acknowledgment (either client or client-individual mode) then the MESSAGE frame MAY also contain an ack header with an arbitrary value. This header, if present, MUST be used to relate the message to a subsequent ACK or NACK frame. Otherwise the message-id header is used."

There two motives here: (a) avoids forcing a change for STOMP servers (clients would still need to be changed to respect the ack header if present) (b) avoids unnecessary duplication and bandwidth usage in cases where the server wants the message-id to be used as the ACK id.

Not sure if this really simplifies things.  If a STOMP server does not want to change he can just remain at the 1.1 protocol and force clients to use that version of the spec.

[Lionel Cons]

Chris Barrow <chris....@kaazing.com> writes:
> Clients that use the STOMP frame instead of the CONNECT frame will only be able to connect to STOMP 1.2 servers
>
> This is incorrect, they can also connect to STOMP 1.1 servers.

In fact, only to _some_ STOMP 1.1 servers (since the STOMP frame was
optional in 1.1). Now fixed in the spec.

> How about avoiding this backwards incompatible change by instead
> making the ack header optional, and stipulating that the client must
> use the message-id as the ACK id if the ack header is absent?

I agree with Hiram that this complicates the spec without bringing
much. We already have backward compatibility via version negotiation,
let's keep the simplicity of this single new header.

> If the intention is to say that transaction identifiers must be unique
> within the same connection, then I would suggest mirroring the
> language used for the SUBSCRIBE id (which I do find it very clear),
> i.e.:
>
> Within the same connection, different transactions MUST use different transaction identifiers.

I've updated the spec accordingly.

Thanks for your comments.

Cheers,

Lionel

[Hiram Chirino]

I've reviewed it and it looks good to me.  Could we drop the bullet item 'sequential processing of frames (FIXME: not yet done…)'?

Regards,

Hiram

On Fri, Sep 14, 2012 at 8:14 AM, Lionel Cons <lione...@cern.ch> wrote:

--

Hiram Chirino

Engineering | Red Hat, Inc.

hchi...@redhat.com | fusesource.com | redhat.com

[Lionel Cons]

Hiram Chirino <hi...@hiramchirino.com> writes:
> I've reviewed it and it looks good to me. Could we drop the bullet

> item 'sequential processing of frames (FIXME: not yet done?)'?

In fact, I've added the clarification for the RECEIPT frame (as discussed
in another thread) and rephrased this bullet. Ok?

Cheers,

Lionel