Sylvestre Ledru
844770494d
Convert services/docs, services/settings/docs, services/sync/docs RST files to MyST-flavored Markdown. Update services/* :ref: targets to the explicit (services-*)= MyST anchors used by the converted files. Also update the still-RST toolkit/components/normandy/docs/index.rst cross-references to match the renamed anchors (components/normandy -> components-normandy, services/remotesettings -> services-remotesettings) so the mutual normandy<->remote-settings :ref: links keep resolving until normandy itself is converted. Differential Revision: https://phabricator.services.mozilla.com/D304221
73 lines
3.2 KiB
Markdown
73 lines
3.2 KiB
Markdown
# Introduction to Sync
|
|
|
|
This document is a brief introduction to how Sync is implemented in desktop Firefox.
|
|
|
|
## General, Historical, Anatomy of a Sync Engine
|
|
|
|
This section describes how Sync used to work - and indeed, how much of it still
|
|
does. While we discuss how this is slowly changing, this context is valuable.
|
|
|
|
For any datatype which syncs, there tends to be 3 parts:
|
|
|
|
### Store
|
|
|
|
The sync `store` interfaces with the actual Firefox desktop store. For example,
|
|
in the `passwords` engine, the "store" is that layer that talks to
|
|
`Services.logins`
|
|
|
|
### Tracker
|
|
|
|
The `tracker` is what knows that something should be synced. For example,
|
|
when the user creates or updates a password, it is the tracker that knows
|
|
we should sync now, and what particular password(s) should be updated.
|
|
|
|
This is typically done via "observer" notifications - `Services.logins`,
|
|
`places` etc all send specific notifications when certain events happen
|
|
(and indeed, some of these were added for Sync's benefit)
|
|
|
|
### Engine
|
|
|
|
The `engine` ties it all together. It works with the `store` and
|
|
`tracker` and tracks its own metadata (eg, the timestamp of the passwords on
|
|
the server, so it knows how to grab just changed records and how to pass them
|
|
off to the `store` so the actual underlying storage can be updated.
|
|
|
|
All of the above parts were typically in the
|
|
{searchfox}`services/sync/modules/engines directory <services/sync/modules/engines>`
|
|
directory and decoupled from the data they were syncing.
|
|
|
|
## The Future of Desktop-Specific Sync Engines
|
|
|
|
The system described above reflects the fact that Sync was "bolted on" to
|
|
Desktop Firefox relatively late - eg, the Sync `store` is decoupled from the
|
|
actual `store`. This has causes a number of problems - particularly around
|
|
the `tracker` and the metadata used by the engine, and the fact that changes
|
|
to the backing store would often forget that Sync existed.
|
|
|
|
Over the last few years, the Sync team has come to the conclusion that Sync
|
|
support must be integrated much closer to the store itself. For example,
|
|
`Services.logins` should track when something has changed that would cause
|
|
an item to be synced. It should also track the metadata for the store so that
|
|
if (say) a corrupt database is recovered by creating a new, empty one, the
|
|
metadata should also vanish so Sync knows something bad has happened and can
|
|
recover.
|
|
|
|
However, this is a slow process - currently the `bookmarks`, `history` and
|
|
`passwords` legacy engines have been improved so more responsibility is taken
|
|
by the stores. In all cases, for implementation reasons, the Sync
|
|
implementation still has a `store`, but it tends to be a thin wrapper around
|
|
the actual underlying store.
|
|
|
|
## The Future of Cross-Platform Sync Engines
|
|
|
|
There are a number of Sync engines implemented in Rust and which live in the
|
|
application-services repository. While these were often done for mobile
|
|
platforms, the longer term hope is that they can be reused on Desktop.
|
|
{doc}`engines` has more details on these.
|
|
|
|
While no existing engines have been replaced with Rust implemented engines,
|
|
the webext-storage engine is implemented in Rust via application-services, so
|
|
doesn't tend to use any of the infrastructure described above.
|
|
|
|
Hopefully over time we will find more Rust-implemented engines in Desktop.
|