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
