eb1f268654
Bumped UniFFI to 0.28.2 Added a tool to run uniffi-bindgen in library mode. It can input either a specific library path or the megazord crate name. Use that simplify several build scripts -- especially the generate docs ones. The best part of this is that we no longer have to maintain hand-written modulemaps, which makes adding a new component harder than it needs to be. Split out the uniffi-bindgen commands from `build-xcframework.sh`. This way you can run them standalone and see the results, even if you don't have XCode setup. One change is that automation/swift-components-docs/generate-swift-project.sh now uses `megazord_ios` rather than `megazord`. I think this should result in slightly more accurate docs, since historically some components in the Android megazord aren't in the iOS one (Although, I think they match at the present). |
||
|---|---|---|
| .. | ||
| android | ||
| ios/SyncManager | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
| build.rs | ||
| metrics.yaml | ||
| pings.yaml | ||
| uniffi.toml | ||
README.md
Sync Manager
The sync manager designed to integrate multiple sync engines/stores into a single coherent framework. There are multiple, independent rust components, all of which know how to sync - but when an app uses multiple components, something must tie them together so that, eg, a single "sync now" function exists to sync all components, and to help the app manage the "enabled" state of these engines. There's other non-obvious "global state" which should also be shared - eg, we only need a single token from the token-server and can share it across all components, if the server is under load and wants clients to back off, that state should be shared.
This crate relies very heavily on sync15, so you should read the
documentation in that crate. Indeed, you can almost see this as a wrapper
around that crate, but there's other "global functionality" managed by this
crate that doesn't fit well in any other place. For example, each application
should have a single "device record" which describes the app and not individual
stores. There's also the concept of "commands" which are sent to a device, and
then delegated to the correct store - those concepts are implemented in this
crate.
Other notes:
It's a bit unfortunate this component can't just be part of sync15.
Conceptually and functionally, it shares most in common with with the sync15
crate, and in some cases stretches (or arguably breaks) the abstraction barrier
that sync15 puts up.
Unfortunately, places/logins/etc depend on sync15 directly, and so to prevent a
dependency cycle (which is disallowed by cargo), doing so would require
implementing the manager in a fully generic manner, with no specific handling of
underlying crates. This seems extremely difficult, so this is split out
into it's own crate, which might happen to reach into the guts of sync15 in
some cases.
Note also that the world has changed a little since then - in particular, we
now have sync15-traits - there might now be an opportunity to move all the
types into that crate, and merge sync15 and sync_manager