Module client

A module for everything needed to be a “sync client” - ie, a device which can perform a full sync of any number of collections, including managing the server state.

In general, the client is responsible for all communication with the sync server, including ensuring the state is correct, and encrypting/decrypting all records to and from the server. However, the actual syncing of the collections is delegated to an external crate::engine(Sync Engine).

One exception is that the “sync client” owns one sync engine - the crate::clients_engine, which is managed internally.

Structs

• MemoryCachedState
  Info we want callers to engine in memory for us so that subsequent syncs are faster. This should never be persisted to storage as it holds sensitive information, such as the sync decryption keys.
• Sync15StorageClient
• Sync15StorageClientInit
• SyncRequestInfo
  This is essentially a bag of information that the sync manager knows, but otherwise we won’t. It should probably be rethought if it gains many more fields.
• SyncResult
  The result of a sync request. This too is from the “sync manager”, but only has a fraction of the things it will have when we actually build that.

Enums

• ServiceStatus
  The general status of sync - should probably be moved to the “sync manager” once we have one!
• Sync15ClientResponse
  A response from a GET request on a Sync15StorageClient, encapsulating all the variants users of this client needs to care about.

Traits

• SetupStorageClient
  A trait containing the methods required to run through the setup state machine. This is factored out into a separate trait to make mocking easier.

Functions

• sync_multiple
  Sync multiple engines
• sync_multiple_with_command_processor
  Like sync_multiple, but specifies an optional command processor to handle commands from the clients collection. This function is called by the sync manager, which provides its own processor.