On 31/07/2013 5:17 AM, Brian Warner wrote:
> On 7/30/13 4:22 AM, Andreas Gal wrote:
>> Also, if we implement our own replication mechanism, what is the
>> advantage of sticking with the CouchDB wire protocol? Its actually
>> rather clumsy and inefficient (see proposed jsondiff delta
>> compression). I am not arguing for using something else than CouchDB.
>> I am merely asking why you think it makes sense to stick with the wire
>> protocol but abandon the higher level semantics of CouchDB.
>
>
> The biggest advantage of sticking with the CouchDB wire protocol is that
> we get to use existing CouchDB implementations on the storage server.
> We'll probably have a proxy in front of it, but that'll be pretty thin.
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)
IMO our time-to-production-ready on the server side will be quite
similar whether we're fronting couchdb or mysql or some other store.
Using CouchDB as a wire protocol becomes more compelling if:
* It lets people stand up their own storage servers really easily,
e.g. by just running CouchDB and pointing firefox at it.
* We outsource the servers to a company with experience running
this at scale, such as https://cloudant.com/
* It provides interesting opportunities for interacting with
a wider software ecosystem.
* It happens to be a nice fit for the problem at hand.
If we're talking about needing a custom write API for transactionality
and a fronting proxy to do auth etc, then I'm not sure any of those
points hold.
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
