Definitely not coming across argumentative and I dont think we particularly disagree on much, not strictly tying ourselves to a particular backend is definitely a good thing as long as it doesnt push scope beyond mvp, which nobody is suggesting.
On 31 July 2013 03:32, Ryan Kelly <[email protected]> wrote: > On 31/07/2013 10:50 AM, Dale Harvey wrote: > >> I don't consider that a significant win *in isolation*. (I also don't > >> consider it a lose; just want to be clear that this is not a killer > >> feature) > > > > If we can avoid atomic multikey updates then in my opinion it is a huge > > win, the architecture looks very similiar to what couchdb was designed > > to handle and rewriting that on top of a database that wasnt designed in > > the same way in a way that is stable and handle a large volume of > > traffic is a huge undertaking, an auth layer is pretty much irrelevant > > in terms of additional work to get a working server (an auth layer > > wouldnt need to sit in front of couchdb, it could just be a token server) > > > > If we have a hard requirement on atomic multikey writes (without any > > possibility of introducing conflicts) then it is a different story in > > terms of time to get a server running, but still a pretty huge task > > I don't want to suggest that the server side is trivial here; it's going > to be a pretty huge task either way. > > If CouchDB's semantics and API are a good fit for what we're trying to > do, great! There's lots to like about it. But if we go too far down > the road of "CouchDB++" then IMHO its value on the server side > deteriorates rapidly. > > I agree that atomic multi-keys writes are probably the boundary of "too > far down that road". > > To sanity-check my understanding: AFAICT the proposed queuesync model > requires only this small set of functionality: > > * JSON records, stored by key, with: > * server-assigned version identifiers > * atomic compare-and-swap > * An API for doing bulk upload of new versions > * maybe with cross-key consistency > * An API for reading back changes, in order > > Have I missed anything? > > This seems straightforward to implement on top of CouchDB, minus the > cross-key consistency part. > > It also seems straightforward to implement on top of the servers we > built and loadtested and almost-deployed for Sync2.0, including the > cross-key consistency part. > > Would it be equivalently straightforward to implement on top of the > Dropbox APIs? > > Without wanting to go Off-MVP here, perhaps this a small core protocol > that we can back with CouchDB for an initial fast-to-market > implementation, but also leave open as a possible integration point for > third-party storage services in the future. > > (I hope this doesn't come across as argumentative. I'm not trying to > advocate against CouchDB here! I just want to be super clear about > where and how we plan to extract value from it, and what we might be > giving up in return.) > > > Cheers, > > Ryan > _______________________________________________ > 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
