Hello sync-dev, Is there documentation on best practices for making a new data type that will eventually be synced? I'm trying to figure out a schema and storage backend for Form Autofill profiles (on desktop to start) and though we're not implementing the sync engine initially, I would like the data to be ready for sync without significant re-implemention of the storage.
On the schema side, an obvious thing is to use a GUID (shorter ones are preferred IIUC) instead of an incrementing ID for the primary key. It seems things like tracking of deleted records and how to handle conflicts between the server and client can be figured out when the engine is added but correct me if I'm wrong? Regarding the storage method, my understanding is that SQLite is used on mobile to provide access to the data from a separate non-Gecko sync process (at least on Android, not sure how things work on iOS). For desktop I would prefer to use a simple JSON file like logins.json since we don't need the features of an RDBMS but it's possible to re-use a SQLite backend between desktop and mobile then I'll consider it. I'm not sure if that's the case though since it seems like each client would write it's own native wrapper around the SQLite (I saw Passwords was moving to a Java implementation on Android though I'm not sure of the motivations for that TBH) in which case very little code would be shared. Thanks, Matthew Noorenberghe (:MattN)
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
