Struct ConfigSyncEngine

pub struct ConfigSyncEngine<T> { /* private fields */ }

Implementations

impl<T> ConfigSyncEngine<T>

pub fn new( config: EngineConfig, store: Arc<Store>, storage_impl: Box<dyn SyncEngineStorageImpl<T>>, ) -> Self

pub fn reset_local_sync_data(&self) -> Result<()>

Trait Implementations

impl<T: SyncRecord + Debug> SyncEngine for ConfigSyncEngine<T>

fn collection_name(&self) -> CollectionName

fn set_local_encryption_key(&mut self, key: &str) -> Result<()>

Tells the engine what the local encryption key is for the data managed by the engine. This is only used by collections that store data encrypted locally and is unrelated to the encryption used by Sync. The intent is that for such collections, this key can be used to decrypt local data before it is re-encrypted by Sync and sent to the storage servers, and similarly, data from the storage servers will be decrypted by Sync, then encrypted by the local encryption key before being added to the local database.

fn prepare_for_sync( &self, _get_client_data: &dyn Fn() -> ClientData, ) -> Result<()>

Prepares the engine for syncing. The tabs engine currently uses this to store the current list of clients, which it uses to look up device names and types.

fn stage_incoming( &self, inbound: Vec<IncomingBso>, telem: &mut Engine, ) -> Result<()>

Stage some incoming records. This might be called multiple times in the same sync if we fetch the incoming records in batches.

fn apply( &self, timestamp: ServerTimestamp, _telem: &mut Engine, ) -> Result<Vec<OutgoingBso>>

Apply the staged records, returning outgoing records. Ideally we would adjust this model to better support batching of outgoing records without needing to keep them all in memory (ie, an iterator or similar?)

fn set_uploaded( &self, new_timestamp: ServerTimestamp, ids: Vec<Guid>, ) -> Result<()>

Indicates that the given record IDs were uploaded successfully to the server. This may be called multiple times per sync, once for each batch. Batching is determined dynamically based on payload sizes and counts via the server’s advertised limits.

fn get_collection_request( &self, server_timestamp: ServerTimestamp, ) -> Result<Option<CollectionRequest>>

The engine is responsible for building a single collection request. Engines typically will store a lastModified timestamp and use that to build a request saying “give me full records since that date” - however, other engines might do something fancier. It can return None if the server timestamp has not advanced since the last sync. This could even later be extended to handle “backfills”, and we might end up wanting one engine to use multiple collections (eg, as a “foreign key” via guid), etc.

fn get_sync_assoc(&self) -> Result<EngineSyncAssociation>

Get persisted sync IDs. If they don’t match the global state we’ll be reset() with the new IDs.

fn reset(&self, assoc: &EngineSyncAssociation) -> Result<()>

Reset the engine (and associated store) without wiping local data, ready for a “first sync”. assoc defines how this store is to be associated with sync.

fn wipe(&self) -> Result<()>

Wipes the engine’s data This is typically triggered by a client command, which at the time of writing, only supported wiping bookmarks.

fn sync_finished(&self) -> Result<(), Error>

Called once the sync is finished. Not currently called if uploads fail (which seems sad, but the other batching confusion there needs sorting out first). Many engines will have nothing to do here, as most “post upload” work should be done in set_uploaded()