overview.rst (3527B)
1 ==================== 2 Introduction to Sync 3 ==================== 4 5 This document is a brief introduction to how Sync is implemented in desktop Firefox. 6 7 General, Historical, Anatomy of a Sync Engine 8 ============================================= 9 10 This section describes how Sync used to work - and indeed, how much of it still 11 does. While we discuss how this is slowly changing, this context is valuable. 12 13 For any datatype which syncs, there tends to be 3 parts: 14 15 Store 16 ----- 17 18 The sync ``store`` interfaces with the actual Firefox desktop store. For example, 19 in the ``passwords`` engine, the "store" is that layer that talks to 20 ``Services.logins`` 21 22 Tracker 23 ------- 24 25 The ``tracker`` is what knows that something should be synced. For example, 26 when the user creates or updates a password, it is the tracker that knows 27 we should sync now, and what particular password(s) should be updated. 28 29 This is typically done via "observer" notifications - ``Services.logins``, 30 ``places`` etc all send specific notifications when certain events happen 31 (and indeed, some of these were added for Sync's benefit) 32 33 Engine 34 ------ 35 36 The ``engine`` ties it all together. It works with the ``store`` and 37 ``tracker`` and tracks its own metadata (eg, the timestamp of the passwords on 38 the server, so it knows how to grab just changed records and how to pass them 39 off to the ``store`` so the actual underlying storage can be updated. 40 41 All of the above parts were typically in the 42 `services/sync/modules/engines directory <https://searchfox.org/mozilla-central/source/services/sync/modules/engines>`_ 43 directory and decoupled from the data they were syncing. 44 45 46 The Future of Desktop-Specific Sync Engines 47 =========================================== 48 49 The system described above reflects the fact that Sync was "bolted on" to 50 Desktop Firefox relatively late - eg, the Sync ``store`` is decoupled from the 51 actual ``store``. This has causes a number of problems - particularly around 52 the ``tracker`` and the metadata used by the engine, and the fact that changes 53 to the backing store would often forget that Sync existed. 54 55 Over the last few years, the Sync team has come to the conclusion that Sync 56 support must be integrated much closer to the store itself. For example, 57 ``Services.logins`` should track when something has changed that would cause 58 an item to be synced. It should also track the metadata for the store so that 59 if (say) a corrupt database is recovered by creating a new, empty one, the 60 metadata should also vanish so Sync knows something bad has happened and can 61 recover. 62 63 However, this is a slow process - currently the ``bookmarks``, ``history`` and 64 ``passwords`` legacy engines have been improved so more responsibility is taken 65 by the stores. In all cases, for implementation reasons, the Sync 66 implementation still has a ``store``, but it tends to be a thin wrapper around 67 the actual underlying store. 68 69 The Future of Cross-Platform Sync Engines 70 ========================================= 71 72 There are a number of Sync engines implemented in Rust and which live in the 73 application-services repository. While these were often done for mobile 74 platforms, the longer term hope is that they can be reused on Desktop. 75 :doc:`engines` has more details on these. 76 77 While no existing engines have been replaced with Rust implemented engines, 78 the webext-storage engine is implemented in Rust via application-services, so 79 doesn't tend to use any of the infrastructure described above. 80 81 Hopefully over time we will find more Rust-implemented engines in Desktop.