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 dd25dca.
The development approach here was roughly the following: I decided the
internal types and interfaces that I wanted to exist, and some of the
implementation details (e.g. the mutations that DefaultRealtimeObjects
performs during a sync sequence). I then asked Cursor to fill in the
most of the implementation and tests (providing it with the relevant
spec text). I have done some tweaking of the code that Cursor generated,
but that doesn't mean that all of the code that's here is exactly the
same as code that I would write, and I'm going to leave it that way.
I have looked through all (and changed some) of the tests that Cursor
generated, and in doing so also fixed the spec conformance tags (because
it got those very wrong), so I am _fairly_ confident that the tests are
testing what they claim to test. But I have not looked at them in minute
detail (in particular, the exact data created by the canned data
factories that it created). I also think that tests are one of those
things where there's not always one right way to write them, so I'm not
going to get hung up on "could it have done this test differently?" or
"are the tests consistent with each other?" at the moment.
There are some outstanding questions on the spec PR at the moment; have
implemented to best of my understanding, and will update later once
those are answered.
Not yet implemented:
- Checking of channel modes before performing operations (RTO2 and the
points that refer to it); there's an outstanding question about this
at [2]
A note re the MutableState pattern that I've used here — done this so
that the class can essentially have mutating instance methods which can
call each other without having to worry about whose responsibility it is
to acquire the mutex.
[1] ably/specification#333
[2] https://github.com/ably/specification/pull/333/files#r2152297442
// Used for synchronizing access to all of this instance's mutable state. This is a temporary solution just to allow us to implement `Sendable`, and we'll revisit it in https://github.com/ably/ably-cocoa-liveobjects-plugin/issues/3.
/// If this returns false, it means that there is currently no stored sync sequence ID or SyncObjectsPool
27
+
internalvartestsOnly_hasSyncSequence:Bool{
28
+
mutex.withLock{
29
+
mutableState.syncSequence !=nil
30
+
}
31
+
}
32
+
33
+
// These drive the testsOnly_waitingForSyncEvents property that informs the test suite when `getRoot()` is waiting for the object sync sequence to complete per RTO1c.
// We only care about the case where HAS_OBJECTS is not set (RTO4b); if it is set then we're going to shortly receive an OBJECT_SYNC instead (RTO4a)
235
+
guard !hasObjects else{
236
+
return
237
+
}
238
+
239
+
// RTO4b1, RTO4b2: Reset the ObjectsPool to have a single empty root object
240
+
// TODO: this one is unclear (are we meant to replace the root or just clear its data?) https://github.com/ably/specification/pull/333/files#r2183493458
// 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.
244
+
245
+
// RTO4b3, RTO4b4, RTO5c3, RTO5c4
246
+
syncSequence =nil
247
+
syncStatus.signalSyncComplete()
248
+
}
249
+
250
+
/// Implements the `OBJECT_SYNC` handling of RTO5.
Copy file name to clipboardExpand all lines: Sources/AblyLiveObjects/Internal/CoreSDK.swift
+7Lines changed: 7 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -6,6 +6,9 @@ internal import AblyPlugin
6
6
/// This provides us with a mockable interface to ably-cocoa, and it also allows internal components and their tests not to need to worry about some of the boring details of how we bridge Swift types to AblyPlugin's Objective-C API (i.e. boxing).
0 commit comments