Thanks for the responses, everyone. So I've been using CouchDB for about a year, but I'm only now getting into the "2.1 Layer Architecture" (cutting back from a 3+ layer).
Apparently I've been using readers and admins wrong all along. I thought that only admins could write documents. After all, why would I think that 'readers' could write? I've been a victim of the misnomer! I still think that the dropbox feature would be immensely useful, and I still might take a whack at implementing it. Thanks for the clarification, --Jonathan On Mon, Jul 11, 2011 at 1:17 AM, Jason Smith <[email protected]> wrote: > On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes > <[email protected]> wrote: > >> Fortunately, users with write access are not admins. They may not > >> modify design documents. All of their changes are subject to design > >> documents' validate_doc_update() function. > > > > I would be *overjoyed* to hear that you are right and the documentation > at > > [0] is wrong: > >> database admins - Defined per database. They have all the privileges > > readers have plus the privileges: write (and edit) design documents, > > add/remove database admins and readers, set the database revisions limit > > > > (/somedb/_revs_limit API) and execute temporary views against the > database > > (/somedb/_temp_view API). They can not create a database and neither > delete > > a database. > > D'oh, Marcello posted a pithy and timely answer while I had lunch. > I'll send anyway. > > The typical setup is: > > * 1 server admin > * 0 or more database admins (name or roles in _security.admins) > * An admin deploys a design document > * Several normal users (name or roles in _security.readers but *not* > admins) > > "readers" is a misnomer. It really means "members." Read access is > database-wide, write access is at the pleasure of > validate_doc_update(). > > To that end, Chris changed CouchDB so that future releases will use > the "members" field. He committed his change last Thanksgiving > weekend. Thanks, Chris! > > > I'm gonna set up a little experiment in the morning (when I can think > > clearly) to find out for myself. The _revs_limit PI and temporary views > are > > scary too. > > I strongly encourage an experiment. 15 or 20 minutes of poking around > will make things very clear. > > Cloudant has a brilliant UI to impose more intuitive and traditional > security policies for exactly this reason. > > >> I call it a 2.5-layer architecture > >> because there is no middleware, but it still requires a third > >> component, to watch over things. The drop box would be amazing; > >> however I am still happy with my architecture because bugs or crashes > >> in the third component are not so devastating to the user experience. > > > > The great thing about this architecture is that you can easily have > CouchDB > > monitor the third party stuff and keep it running with external OS > processes > > [1]. I like the term '2.5-layer' :D. > > Is it too late to change the name to "2.1-layer"? > > * Hints that the extra step is not going to break your back > * Kind of like 5.1 surround sound > > > By the way, why hasn't this been implimented before? It seems strange to > me. > > Is there something inherent in the architecture of CouchDB that makes > this > > difficult? > > I think it is a matter of time. The people in a position to implement > it have not felt quite enough pressure. > > /me whistles innocently. > > -- > Iris Couch >
