> > I guess it depends on how we would want to handle a conflict where two > clients changed their phone numbers (added or removed) before a sync > happened. Some methods for handling that would require more than just an > array of strings containing phone numbers e.g. timestamps. >
You can make the record reconciler as complicated as you wish; indeed, if you store all local changes, the shared parent, and buffer the incoming record you could essentially write your own one-big-JSON-blob synchronizer. The rule for Sync is: if two things are related (that is: changes to one must be seen at the same time as another), then they should be in the same record. That can mean lots of separate records, or several big records, or even one huge record (if you can fit it in 256K). I said I'd consider using SQLite for desktop if we can share > implementation code. I guess I was hoping for a shared JS-implemented > version but didn't think that would be usable on iOS, for example (at least > I don't think storage-mozStorage.js was used for passwords on iOS). Your expectations are correct: storage on iOS is a wholly different beast. It seems like these same motivations would apply to form autofill profiles > and therefore I likely wouldn't be able to share a JS-implemented storage > implementation, right? If you use JSON, it needs to be owned by Java. If you use SQLite, it can be reused, but it's a little painful. Our experience is that it's easier to just write the whole thing again in Java than it is to use Gecko code.
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
