On Jul 24, 2013, at 1:26 PM, Mark Finkle <[email protected]> wrote:
> In general, I like the idea of using some form of client-side adapter to > insulate the client from protocol/storage changes. You are pushing the > SyncableService API and I don't have any reasons to go against it. It seems > like a nice adapter. What would the expectation in agreeing upon SyncableServiceAPI be? Do we gain actual code portability between implementations, or is it simply a better architecture across clients? > I do have a question, mainly semantics: You talk about using the Dropbox File > API to handle syncing independent records, but my first reaction would be to > use the Dropbox Storage API, which seems tailor made for records. What's your > rationale for using File API over the Storage API? > > Lastly, I worry about any local shadow data storage, mainly due to space > considerations on mobile devices. That said, we need real prototypes to get > an idea of just how much space would be consumed. It's never free, but I > think we need to find a compromise. The thing I liked about chris's thinking was "I don't envision needing a local CouchDB shadow copy of data". That's the second time I've heard someone conclude that this is possible given the constraints we're dealing with. lloyd > > In preparation of our design review, I spent a good part of yesterday trying > to digest the pros and cons of Dropbox API, CouchDB API, and TreeSync (which > I'm frankly still a bit fuzzy about). > > In short, can we get a Triple Win, where can benefit from the pros of all > three of these options? > > Observation 1: The CouchDB API or the Dropbox File API is likely good enough > for syncing independent (or even mostly independent) records (e..g, history, > passwords, tabs). Future stuff like calendar events, contacts, reading list, > etc. might fall in this category too. > > Observation 2: Bookmarks are hairy because there is structure, and changes > should probably be more transactional than what the CouchDB and Dropbox APIs > provide. We might be able to alter the Couch API slightly or work within it > to address these issues. It probably wouldn't be as good as a more tailored > solution, but it might be good enough! Weird things might still happen, but > we could accept it, particularly if users are moving away from maintaining > structured bookmarks. The upside is that we could potentially move quickly. > > Observation 3: It would be nice to have clean API boundaries and composable > subsystems. For example, it would be nice if we could have a simple API > between the content/data provider (e.g., the history component) and the sync > mediator (the thing responsible for talking to the storage server). This > could allow us to change (or allow the user to choose!) a storage provider > without having to make substantial changes to the content providers. > Likewise, content providers should handle their own merge conflicts. I would > also like new content providers to be able to make substantial progress on > integrating with sync without a lot of hand-holding from experts. Many of you > are aware that I like the idea of the Syncable Service API in Chromium, which > has similar goals. Here's a nice talk on it: > https://docs.google.com/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDo2MzU1NDEwZTA1NTUwNzlk > > Triple Win?: Most datatypes would be fine with Couch or Dropbox. I propose we > consider a structure where the sync/wire protocol could be either the CouchDB > or Dropbox API and *data types that need more (e.g., bookmarks)* can layer > additional mechanisms on top of that. For example, TreeSync could run on top > of an abstraction backed by either the CouchDB API or Dropbox API (I think > they are close enough that we can pull that off). Brian and I brainstormed > how one might do this yesterday, and the idea has legs. > > I call this a potential Triple Win, because if it works, then we could get > the "already debugged, already there" wins from both Couch and Dropbox, we > get the integrity win of TreeSync, and we get the Dropbox > offload-some-server-storage win if that somehow makes sense. > > In this world, I don't envision needing a local CouchDB shadow copy of data > (although it isn't ruled out). Instead, this sync mediator component serves a > CouchDB or Dropbox proxy, which may do some caching of data for performance > purposes. > > -chris > > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev > > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
