On Fri, Aug 26, 2011 at 10:01 PM, Jason Smith <[email protected]> wrote: > On Sat, Aug 27, 2011 at 9:09 AM, Randall Leeds <[email protected]> > wrote: >>> The issue here is that adding a revision tree most likely means a >>> requirement that the HTTP API changes to use MVCC tokens. >> >> _local docs already do. They just don't support ?new_edits, or >> revs_info/revs/open_revs/meta, though I'd have to check.. It's not a hard >> requirement that we support this stuff. And certainly the old /_security >> endpoint could completely paper over this if we just make it clobber (which >> no one on vanilla couch should care about). > > I propose there is no more /_security HTTP endpoint. > > Instead, _local docs get full MVCC support. You can post conflicts > with ?new_edits=false and resolve them normally. The API becomes > smaller and also more consistent. > > Next, _local/security is special to CouchDB. Upon an update, the > current winning revision is cached in the DB header. This allows couch > to quickly confirm read or admin permission when using the DB, and > send secObj to validate_doc_update. > > Does this sound reasonable? I see two bonuses: > > 1. Full MVCC for _local would be nice for users, who are using _local > more. If it's worth storing, it's worth storing in MVCC. > 2. Design docs can validate the security policy. > > I can think of two issues: > > 1. Does this require updating the replicator to update _local docs correctly? > 2. Only admins can change _security. But anybody with read access can > change _local/*. Does couch special-case _local/security? > > -- > Iris Couch >
1. You assume users using _local want conflicts there. In node local data I don't see the benefit. Revision merging is for merging revisions when writes happen in different order on different nodes. Introducing revisions into something that should never have conflicts seems... unproductive. 2. Now we're introducing super special consideration into specific doc ids. Do not want. I'm not the biggest fan of the current _security API. I'm also not a fan of "Everything is a database!" I didn't like _users as a database. I was quite irritable about _replicator as a database. I'm fine reusing code internally, but promoting these internals to database level introduces some questions I've never seen answered. Putting _security into this same level scares the bejezzus out of me.
