Clarify reason for bundling constraint; add contiguousness constraint #521
Conversation
|
Is there an argument also for not bundling messages for channel A if there is an intervening message for channel B? |
But a |
If the sequence of published messages is 1 (channel A), 2 (channel B), 3 (channel A), the library might bundle 1 and 3 into a single protocol message. |
Well we don't have an API yet to publish messages not on channels (this being discussed in client Transient publishing for 1.2, so should we not add a note in there as that is the only API that would allow this, or am I missing how this would be relevant with the current API? |
FWIW ably-js currently satisfies that anyway, just because its queue function only ever checks the most recent message in the queue. But I also don't follow why it'd be a problem if a client library did do it, given we don't preserve message ordering across channels anyway
I don't see how the different publish api is relevant? |
Just because you will have messages from that connection whose msgSerial is not in the same order as the client requested their publication. |
|
ok. not sure it matters much, but shrug, happy to add it if you like, no strong feelings |
|
I do think we should impose that constraint |
| @@ -502,7 +502,8 @@ h3(#realtime-channel). Channel | |||
| *** @(RTL6c5)@ A publish should not trigger an implicit attach (in contrast to earlier version of this spec) | |||
| ** @(RTL6d)@ Messages for a single channel that have been queued may be sent in a single @ProtocolMessage@ by bundling them into the @ProtocolMessage#messages@ array, subject to the following constraints: | |||
| *** @(RTL6d1)@ The resulting @ProtocolMesssage@ must not exceed the @maxMessageSize@ | |||
| *** @(RTL6d2)@ Messages with differing @clientId@ values must not be bundled together | |||
| *** @(RTL6d2)@ Messages with differing @clientId@ values must not be bundled together. (Note that this constraint only applies to what the client library can autonomously do as part of queuing messages, not to what the user can do by publishing an array of @Messages@. It exists because if any @Message@ in a @ProtocolMessage@ has an invalid @clientId@, the entire @ProtocolMessage@ is rejected. This is fine if the user has deliberately published the @Messages@ together – they requested atomicity – but not if the client library has bundled them without the user's knowledge) | |||
There was a problem hiding this comment.
I think it should be explicit that messages can only be bundled if their clientIds are identical, or identically empty.
There was a problem hiding this comment.
Not sure I see the ambiguity (spec says "differing clientId values", "foo" and null are definitely not the same value). But shrug, guess it doesn't do any harm to be overexplicit
SimonWoolf
force-pushed
the
bundling-clarification
branch
from
69bb6f1 to
80fc3dc
Compare
|
Latest: 80fc3dc |
As suggested in https://ably-real-time.slack.com/archives/C030C5YLY/p1537879666000200 .
Also added RTL6d3 to make the preserve-ordering constraint explicit (I guess we didn't think to include originally because it was too obvious to mention, but better to be explicit)