Done. The main syncing observations are around dates; I think storing creation and modified times is fine, so long as you apply some careful thought when syncing those values (and we can cross that bridge when we come to it).
I left some pointers to the two relevant "Falsehoods programmers believe about…", which should be enough encouragement to store an arbitrarily large unconstrained "name" field rather than thinking about concatenation, and detail fields (a concession to bad data models on the web) instead of trying to split. I also left a test case for you. Similarly, try to make the address field(s) as unconstrained as possible: addresses can even have multiple countries, so once again the world and ecommerce sites collide :) On Thu, Sep 22, 2016 at 12:56 AM, Luke Chang <lch...@mozilla.com> wrote: > Hi Richard, Nicholas and syn-dev, > > We've come up with our first version of the form autofill schema and would > like to share with you (see [1]). > > Also, since JS-implementation on top of SQLite is not that reusable for > other devices, we will simply use JSON-based storage and leverage the > existing module used in Password Manager [2]. > > Any feedback are welcome. > > Thanks, > Luke > > [1] https://docs.google.com/document/d/1HsJCn5XtWKD3kWupZQ6o > XgHeEp3Dq1Z88xWSCO3weLY/edit?usp=sharing > [2] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/ > passwordmgr/LoginStore.jsm > > > 2016-09-03 9:27 GMT+08:00 Richard Newman <rnew...@mozilla.com>: > >> 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 Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
