Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify reason for bundling constraint; add contiguousness constraint #521

Merged
merged 2 commits into from
Oct 2, 2018
Merged

Clarify reason for bundling constraint; add contiguousness constraint #521

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f44d931
Clarify reason for bundling constraint; add contiguousness constraint
SimonWoolf Sep 25, 2018
80fc3dc
More clarifications to bundling
SimonWoolf Oct 1, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions content/client-lib-development-guide/features.textile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -504,9 +504,13 @@ h3(#realtime-channel). Channel
*** @(RTL6c2)@ If the connection is @INITIALIZED@, @CONNECTING@ or @DISCONNECTED@, and @ClientOptions#queueMessages@ has not been explicitly set to false, then the message will be queued and delivered as soon as the connection is @CONNECTED@ and the channel is in a state in which publishing is permitted per @RTL6c1@
*** @(RTL6c4)@ If the connection is @SUSPENDED@, @CLOSING@, @CLOSED@, or @FAILED@, or the channel is @SUSPENDED@ or @FAILED@, the operation will result in an error
*** @(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:
** @(RTL6d)@ Messages that have been queued may be sent in a single @ProtocolMessage@ by bundling them into the @ProtocolMessage#messages@ or @ProtocolMessage#presence@ array, subject to the following constraints:
*** @(RTL6d1)@ The resulting @ProtocolMessage@ must not exceed the @maxMessageSize@
*** @(RTL6d2)@ Messages with differing @clientId@ values must not be bundled together
*** @(RTL6d2)@ Messages can only be bundled together if they have the same @clientId@ value (or both have no @clientId@ set). (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)
*** @(RTL6d3)@ Messages can only be bundled together if they are for the same @channel@
*** @(RTL6d4)@ Messages can only be bundled together if they are of the same type (that is, @Message@ versus @PresenceMessage@)
*** @(RTL6d5)@ Only contiguous messages in the queue can be bundled together. For example, if the user publishes three messages, A, B, and C, of which A and C could be bundled together under @RTL6d1-4@ but B could not, then no bundling should occur
*** @(RTL6d6)@ The order of messages in the resulting @ProtocolMessage@ Messages must match the publish order. For example, if the user publishes @Message@ D, then the @Message@ array [E, F], then @Message@ G, the final @messages@ array should be [D, E, F, G]
** @(RTL6e)@ Unidentified clients using "Basic Auth":https://en.wikipedia.org/wiki/Basic_access_authentication (i.e. any @clientId@ is permitted as no @clientId@ specified):
*** @(RTL6e1)@ When a @Message@ with a @clientId@ value is published, Ably will accept and publish that message with the provided @clientId@. A test should assert that the @clientId@ of the published @Message@ is populated
** @(RTL6g)@ Identified clients with a @clientId@ (as a result of either an explicitly configured @clientId@ in @ClientOptions@, or implicitly through Token Auth):
Expand Down