application-services/components/sync_manager
lougeniac64 cc29c6925f Removed obsolete iOS sync logic 2023-07-17 22:39:21 +00:00
..
android move/port sync manager metrics from android into appservices and rename to fix iOS name collision 2023-06-07 00:52:32 +00:00
ios/SyncManager move/port sync manager metrics from android into appservices and rename to fix iOS name collision 2023-06-07 00:52:32 +00:00
src Upgrading to UniFFI 0.24 and Glean to 53.1.0 2023-07-05 20:48:54 +00:00
Cargo.toml Removed obsolete iOS sync logic 2023-07-17 22:39:21 +00:00
README.md Update README for sync15 and sync_manager (#3753) 2020-12-14 14:24:42 +11:00
build.rs Updating UniFFI to version 0.23 2023-01-27 12:38:55 -05:00
metrics.yaml move/port sync manager metrics from android into appservices and rename to fix iOS name collision 2023-06-07 00:52:32 +00:00
pings.yaml move/port sync manager metrics from android into appservices and rename to fix iOS name collision 2023-06-07 00:52:32 +00:00
uniffi.toml Remove duplicate DeviceType enums. (#5316) 2023-04-28 05:35:26 +10:00

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 delgated 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