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
