On Jul 24, 2013, at 12: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. > I'm not convinced that the SyncableService API is perfect as-is, but it can at least serve as a straw man for people to react against. I've gotten minimal feedback about it so far, which is partly why I keep shoving it in peoples' faces. For example, in the context of the structure I just described, I think there should be a SyncMediator -> ContentProvider channel for communicating conflicts (i.e., the SyncMediator tried to push to the server, and it failed, so it needs to request a merge from the ContentProvider). > 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. Yeah, I'm worried about that as well. It may not have been clear from my previous email, but my thinking about this has been moving *away from* full local shadow data storage. The SyncMediator would primarily serve as an adapter to the StorageProvider. It may have some storage requirements for performance/translation reasons, but I don't think it needs to provide a full shadow copy. And yes, prototypes and better specified designs are a requirement to understand this better. -chris > > 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
