couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Scholl ...@diskware.net>
Subject Re: Partial replication -orelse- sending interpreted data to another server
Date Mon, 16 Feb 2009 18:54:10 GMT
Damien Katz wrote:
> The problem with b) admin-enforced replication policies is that it's not
> really possible. The replicator is just an agent of the user who invoked
> it, it can choose to follow some rules set by the admin, or it follows
> it's own rules. You can't give a user access to the database, but
> enforce that they can only replicate it the admin specified way. If the
> user can perform a certain update in the database using regular methods,
> he can also do so via the replicator.
Agreed. I thought about a model of making partial replication "with a
user agreeing to a certain contract". One idea that flew around was a
client to send javascripts, which in turn get executed server-side (imho
a security nightmare, to be clear).

What I had in mind when the discussion came up, was a different usage
scenario, namely Jens Alfke's vision of web3.0 with loosely coupled
CouchDB instances replicating each other's datasets.
For this case (e.g. "I want the CS-section of Wikipedia on my iPhone,
not everything else like videos, etc."), I regard a partial replication
as a feature. Everything that helps me reduce the load on either
Wikipedia, or my phone, makes me happy and makes the whole system be
more suitable[1].

> 
> Therefore the answer is to not distinguish between replicated updates
> and direct updates. Instead enforce same security rules either way. This
> user can update this document with these values, or he can't. Doesn't
> matter if it's replicated or direct.
Pragmatic. Agreed.


Martin

[1] "scale" :-)

Mime
View raw message