Skip to content

[WIP] Rename SyncObjectsPool to SyncObjectMessages and clarify its type #370

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

[WIP] Rename SyncObjectsPool to SyncObjectMessages and clarify its type #370

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
11 changes: 6 additions & 5 deletions textile/objects-features.textile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,22 +108,23 @@ h3(#realtime-objects). RealtimeObjects
*** @(RTO4b1)@ All objects except the one with id @root@ must be removed from the internal @ObjectsPool@
*** @(RTO4b2)@ The data for the @LiveMap@ with id @root@ must be cleared by setting it to a zero-value per "RTLM4":#RTLM4. Note that the client SDK must not create a new @LiveMap@ instance with id @root@; it must only clear the internal data of the existing @LiveMap@ with id @root@
**** @(RTO4b2a)@ Emit a @LiveMapUpdate@ object for the @LiveMap@ with ID @root@, with @LiveMapUpdate.update@ consisting of entries for the keys that were removed, each set to @removed@
*** @(RTO4b3)@ The @SyncObjectsPool@ list must be cleared
*** @(RTO4b3)@ The @SyncObjectMessages@ list must be cleared
*** @(RTO4b5)@ The @BufferedObjectOperations@ list must be cleared
*** @(RTO4b4)@ Perform the actions for objects sync completion as described in "RTO5c":#RTO5c
* @(RTO5)@ The realtime system reserves the right to initiate an objects sync of the objects on a channel at any point once a channel is attached. A server initiated objects sync provides Ably with a means to send a complete list of objects present on the channel at any point
** @(RTO5d)@ If an @OBJECT_SYNC@ @ProtocolMessage@ is received and "@ObjectMessage.object@":../features#TR4r is null or omitted, the client library should skip processing that @ProtocolMessage@
** @(RTO5a)@ When an @OBJECT_SYNC@ @ProtocolMessage@ is received with a @channel@ attribute matching the channel name, the client library must parse the @channelSerial@ attribute:
*** @(RTO5a1)@ The @channelSerial@ is used as the sync cursor and is a two-part identifier: @<sequence id>:<cursor value>@
*** @(RTO5a2)@ If a new sequence id is sent from Ably, the client library must treat it as the start of a new objects sync sequence, and any previous in-flight sync must be discarded:
**** @(RTO5a2a)@ The @SyncObjectsPool@ list must be cleared
**** @(RTO5a2a)@ The @SyncObjectMessages@ list must be cleared
**** @(RTO5a2b)@ The @BufferedObjectOperations@ list must be cleared
*** @(RTO5a3)@ If the sequence id matches the previously received sequence id, the client library should continue the sync process
*** @(RTO5a4)@ The objects sync sequence for that sequence identifier is considered complete once the cursor is empty; that is when the @channelSerial@ looks like @<sequence id>:@
*** @(RTO5a5)@ An @OBJECT_SYNC@ may also be sent with no @channelSerial@ attribute. In this case, the sync data is entirely contained within the @ProtocolMessage@
** @(RTO5b)@ During the sync sequence, the "@ObjectMessage.object@":../features#TR4r values from incoming @OBJECT_SYNC@ @ProtocolMessages@ must be temporarily stored in the internal @SyncObjectsPool@ list
** @(RTO5b)@ During the sync sequence, the "@ObjectMessage.object@":../features#TR4r values from incoming @OBJECT_SYNC@ @ProtocolMessages@ must be temporarily stored in the internal @SyncObjectMessages@ list
*** @(RTO5b1)@ @SyncObjectMessages@ is a temporary internal array of @ObjectState@ values used during the sync sequence
** @(RTO5c)@ When the objects sync has completed, the client library must perform the following actions in order:
*** @(RTO5c1)@ For each @ObjectState@ in the @SyncObjectsPool@ list:
*** @(RTO5c1)@ For each @ObjectState@ in the @SyncObjectMessages@ list:
**** @(RTO5c1a)@ If an object with @ObjectState.objectId@ exists in the internal @ObjectsPool@:
***** @(RTO5c1a1)@ Replace the internal data for the object as described in "RTLC6":#RTLC6 or "RTLM6":#RTLM6 depending on the object type, passing in current @ObjectState@
***** @(RTO5c1a2)@ Store the @LiveObjectUpdate@ object returned by the operation, along with a reference to the updated object
Expand All @@ -137,7 +138,7 @@ h3(#realtime-objects). RealtimeObjects
*** @(RTO5c7)@ For each previously existing object that was updated as a result of "RTO5c1a":#RTO5c1a, emit the corresponding stored @LiveObjectUpdate@ object from "RTO5c1a2":#RTO5c1a2
*** @(RTO5c6)@ @ObjectMessages@ stored in the @BufferedObjectOperations@ list are applied as described in "RTO9":#RTO9
*** @(RTO5c3)@ Clear any stored sync sequence identifiers and cursor values
*** @(RTO5c4)@ The @SyncObjectsPool@ must be cleared
*** @(RTO5c4)@ The @SyncObjectMessages@ list must be cleared
*** @(RTO5c5)@ The @BufferedObjectOperations@ list must be cleared
* @(RTO6)@ Certain object operations may require creating a zero-value object if one does not already exist in the internal @ObjectsPool@ for the given @objectId@. This can be done as follows:
** @(RTO6a)@ If an object with @objectId@ exists in @ObjectsPool@, do not create a new object
Expand Down
Loading