diff --git a/textile/objects-features.textile b/textile/objects-features.textile index 0aa742d0..6d651316 100644 --- a/textile/objects-features.textile +++ b/textile/objects-features.textile @@ -110,7 +110,7 @@ h3(#realtime-objects). RealtimeObjects *** @(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 -*** @(RTO4b5)@ The @BufferedObjectOperations@ 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@ @@ -119,7 +119,7 @@ h3(#realtime-objects). RealtimeObjects *** @(RTO5a1)@ The @channelSerial@ is used as the sync cursor and is a two-part identifier: @:@ *** @(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 -**** @(RTO5a2b)@ The @BufferedObjectOperations@ 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 @:@ *** @(RTO5a5)@ An @OBJECT_SYNC@ may also be sent with no @channelSerial@ attribute. In this case, the sync data is entirely contained within the @ProtocolMessage@ @@ -137,10 +137,10 @@ h3(#realtime-objects). RealtimeObjects *** @(RTO5c2)@ Remove any objects from the internal @ObjectsPool@ for which @objectId@s were not received during the sync sequence **** @(RTO5c2a)@ The object with ID @root@ must not be removed from @ObjectsPool@, as per "RTO3b":#RTO3b *** @(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 +*** @(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 -*** @(RTO5c5)@ The @BufferedObjectOperations@ list must be cleared +*** @(RTO5c5)@ The @bufferedObjectOperations@ list must be cleared *** @(RTO5c8)@ The "RTO17":#RTO17 sync state must transition to @SYNCED@ * @(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 @@ -149,10 +149,10 @@ h3(#realtime-objects). RealtimeObjects *** @(RTO6b2)@ If the parsed type is @map@, create a zero-value @LiveMap@ per "RTLM4":#RTLM4 in the @ObjectsPool@ *** @(RTO6b3)@ If the parsed type is @counter@, create a zero-value @LiveCounter@ per "RTLC4":#RTLC4 in the @ObjectsPool@ * @(RTO7)@ The client library may receive @OBJECT@ @ProtocolMessages@ in realtime over the channel concurrently with @OBJECT_SYNC@ @ProtocolMessages@ during the object sync sequence ("RTO5":#RTO5). Some of the incoming @OBJECT@ messages may have already been applied to the objects described in the sync sequence, while others may not. Therefore, the client must buffer @OBJECT@ messages during the sync sequence so that it can determine which of them should be applied to the objects once the sync is complete. See "RTO8":#RTO8 -** @(RTO7a)@ An internal @BufferedObjectOperations@ should be used to store the buffered @ObjectMessages@, as described in "RTO8a":#RTO8a. @BufferedObjectOperations@ is an array of @ObjectMessage@ instances +** @(RTO7a)@ The @RealtimeObjects@ instance has an internal attribute @bufferedObjectOperations@, which is an array of @ObjectMessage@ instances. This is used to store the buffered @ObjectMessages@, as described in "RTO8a":#RTO8a. *** @(RTO7a1)@ This array is empty upon @RealtimeObjects@ initialization * @(RTO8)@ When the library receives a @ProtocolMessage@ with an action of @OBJECT@, each member of the @ProtocolMessage.state@ array (decoded into @ObjectMessage@ objects) is passed to the @RealtimeObjects@ instance per "RTL1":../features#RTL1. Each @ObjectMessage@ from @OBJECT@ @ProtocolMessage@ (also referred to as an @OBJECT@ message) describes an operation to be applied to an object on a channel and must be handled as follows: -** @(RTO8a)@ If the "RTO17":#RTO17 sync state is not @SYNCED@, add the @ObjectMessages@ to the internal @BufferedObjectOperations@ array +** @(RTO8a)@ If the "RTO17":#RTO17 sync state is not @SYNCED@, add the @ObjectMessages@ to the internal @bufferedObjectOperations@ array ** @(RTO8b)@ Otherwise, apply the @ObjectMessages@ as described in "RTO9":#RTO9 * @(RTO9)@ @OBJECT@ messages can be applied to @RealtimeObjects@ in the following way: ** @(RTO9a)@ For each @ObjectMessage@ in the provided list: