You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on [1] at 29276a5. I wrote the implementation, and for the tests
followed the development approach described in cb427d8.
[1] ably/specification#343
Copy file name to clipboardExpand all lines: Sources/AblyLiveObjects/DefaultRealtimeObjects.swift
+47-19Lines changed: 47 additions & 19 deletions
Original file line number
Diff line number
Diff line change
@@ -23,7 +23,7 @@ internal final class DefaultRealtimeObjects: RealtimeObjects, LiveMapObjectPoolD
23
23
}
24
24
}
25
25
26
-
/// If this returns false, it means that there is currently no stored sync sequence IDor SyncObjectsPool
26
+
/// If this returns false, it means that there is currently no stored sync sequence ID, SyncObjectsPool, or BufferedObjectOperations.
27
27
internalvartestsOnly_hasSyncSequence:Bool{
28
28
mutex.withLock{
29
29
mutableState.syncSequence !=nil
@@ -45,6 +45,11 @@ internal final class DefaultRealtimeObjects: RealtimeObjects, LiveMapObjectPoolD
45
45
46
46
/// The `ObjectMessage`s gathered during this sync sequence.
47
47
internalvarsyncObjectsPool:[ObjectState]
48
+
49
+
/// `OBJECT` ProtocolMessages that were received during this sync sequence, to be applied once the sync sequence is complete, per RTO7a.
50
+
///
51
+
/// Note that we only ever populate this during a multi-`ProtocolMessage` sync sequence. It is not used in the RTO4b or RTO5a5 cases where the sync data is entirely contained within a single ProtocolMessage, because an individual ProtocolMessage is processed atomically and hence there's no way for an OBJECT to be processed in the middle of processing the sync data in those cases.
/// Tracks whether an object sync sequence has happened yet. This allows us to wait for a sync before returning from `getRoot()`, per RTO1c.
@@ -255,7 +260,7 @@ internal final class DefaultRealtimeObjects: RealtimeObjects, LiveMapObjectPoolD
255
260
256
261
// I have, for now, not directly implemented the "perform the actions for object sync completion" of RTO4b4 since my implementation doesn't quite match the model given there; here you only have a SyncObjectsPool if you have an OBJECT_SYNC in progress, which you might not have upon receiving an ATTACHED. Instead I've just implemented what seem like the relevant side effects. Can revisit this if "the actions for object sync completion" get more complex.
257
262
258
-
// RTO4b3, RTO4b4, RTO5c3, RTO5c4
263
+
// RTO4b3, RTO4b4, RTO4b5, RTO5c3, RTO5c4, RTO5c5
259
264
syncSequence =nil
260
265
syncStatus.signalSyncComplete()
261
266
}
@@ -275,6 +280,8 @@ internal final class DefaultRealtimeObjects: RealtimeObjects, LiveMapObjectPoolD
275
280
276
281
// If populated, this contains a full set of sync data for the channel, and should be applied to the ObjectsPool.
277
282
letcompletedSyncObjectsPool:[ObjectState]?
283
+
// If populated, this contains a set of buffered inbound OBJECT messages that should be applied.
// Tests that when an OBJECT ProtocolMessage is received during a sync sequence, its operations are buffered per RTO8a and applied after sync completion per RTO5c6.
0 commit comments