From dev-return-8564-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 08 22:29:47 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 78258 invoked from network); 8 Feb 2010 22:29:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Feb 2010 22:29:47 -0000 Received: (qmail 25524 invoked by uid 500); 8 Feb 2010 22:29:46 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 25455 invoked by uid 500); 8 Feb 2010 22:29:46 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 25445 invoked by uid 99); 8 Feb 2010 22:29:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Feb 2010 22:29:46 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates 209.85.216.203 as permitted sender) Received: from [209.85.216.203] (HELO mail-px0-f203.google.com) (209.85.216.203) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 08 Feb 2010 22:29:36 +0000 Received: by pxi41 with SMTP id 41so7281222pxi.27 for ; Mon, 08 Feb 2010 14:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=zF5meijFwET2XielD5OT8wbAn6T/AkRIkI1DbNTsZe8=; b=ZNeHwSnffGtBqmRenlhtDA8GxrH+dVq/+g5KoXpdO5KiJDWujmO0kOyO2InJVGNNyo 3t7S1LvERUSyESAY44xToruOVe/+ccGVGTc68svBSCs9YMMZKvM5g3/oP2AoQa6lv+2g o7zLjJ5E3BXzzyCIYkaOWfDk/SlC6XUq+rlYo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=latmK8QZrZVyF2olCONiTQ2cTCrpKKKIJUGK4Po8EpqBpiO6QpLovGQfDAx5RT9tRD 8wpLXzQgrk3xWi/c3kgo2aREXzEbS37kSS5qoaGmzSarPTnh8/u6cK2zcbUWdrawOMCi cF1dj2vQWFHRcEPaCm9G59jHmtWFpl19QnT3A= MIME-Version: 1.0 Sender: jchris@gmail.com Received: by 10.143.24.17 with SMTP id b17mr4672864wfj.266.1265668154572; Mon, 08 Feb 2010 14:29:14 -0800 (PST) In-Reply-To: <004201caa909$541df650$fc59e2f0$@com> References: <919E5559-B8DE-4B9A-9A6B-DCF3EF18F28C@apache.org> <004201caa909$541df650$fc59e2f0$@com> Date: Mon, 8 Feb 2010 14:29:14 -0800 X-Google-Sender-Auth: 9e5233456c5661fc Message-ID: Subject: Re: Getting to 1.0, Time for 0.11.0 + Feature Freeze From: Chris Anderson To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Feb 8, 2010 at 1:54 PM, James Hayton wr= ote: > Hello Everyone, > > My humble opinion. Please don't bite my head off :P > > I have no problem with releasing 0.11.0, but I don't think couchdb is not > ready for a feature freeze yet. =A0Well, maybe that depends on what every= one > considers to be a new feature. =A0I guess what I am trying to say is that= I > don't think couchdb is ready for 1.0 until it fully supports more robust > authorization. =A0If the remaining work to be done regarding authorizatio= n is > considered a new "feature" then I would definitely be -1 on a feature > freeze. =A0I also think we need some time for the authorization stuff to > settle for a bit and it might be wise to have another release before full= y > committing to support and extend the current model. =A0The work Chris has= done > in trunk is a great step forward, but there are still things missing as f= ar > as I can tell that are really important to practical real world use of > couchdb. > > The innovation/appeal to couchdb really boils down to self hosted > applications and replication. =A0There may be a few other features such a= s > http communication, but outside of those two main features I could swap > couch for mongodb, persevere, riak, etc... and I would probably be able t= o > develop most applications just as well as I could using couchdb. =A0The p= oint > is there are tons of options in the nosql space and the things that reall= y > separate couch from the rest are replication and self hosted applications= . > It's good to hear that you are coming to your use of authorization from the angle we're eager to support. > With all that being said my hunch is that the really cool applications we > will see from couch will revolve around those two features. =A0The bigges= t > thing limiting those applications from actually being built is better > authorization. =A0I know I can throw up a reverse proxy and achieve what = I > need to do most likely, but what happens if I want to package couch insid= e > titanium and serve up an application that contains data for more than one > user locally. =A0 I don't want to install nginx across 100's of client > machines. =A0I want to keep things simple. =A0Currently my only option wo= uld be > to use separate databases since that's the only authorization level that > couch supports. I'm proud to suggest that you should use separate databases. ;) > But at the current time, every user would still be able to > see the name of every other users database via _all_dbs and _users databa= se > is accessible to all. =A0There is also the inability to join views from t= wo > databases, which makes the solution of using separate databases much less > attractive. =A0( I don't want to do that sort of stuff in the client.) I think per-document access control is a bad idea. The gist of it is that keeping track of who can see which map rows (and then making reduce respect those controls) can't be done in a performant and space efficient way. I'd rather put resources towards making db-level access control more useful (cross-database view queries as you mentioned above, better _all_dbs support, etc) than attempt to add an ill-fated "solution" like per-document access control. It is theoretically possible that we could have a per-document access control model that would work, but the amount of complexity required vs the benefit we'd see makes me personally uninterested in such a feature. I'm glad you are rooting for Couch to succeed for the sorts of apps I'm excited about. In writing the access control stuff, I tried to shoot for the 80% solution, because the last 20% is where the majority of complexity comes in. > Clearly, the best and most flexible solution would be to have proper > authorization per resource. =A0 Couch is restful and it ideally should be= able > to handle authorization on the database, document and views levels. =A0In= my > opinion couch is not ready to be released as 1.0 software until it does j= ust > that. Handling authorization in couch is a really important feature for > local, replicating self hosted simple applications. Without this > authorization, the appeal of couch drops dramatically for me. > > Maybe I am missing something and I would love to hear everyone's thoughts= ... > I am a little bit of a dummy sometimes so forgive me if I am totally off = my > rocker here. =A0I don't want to be barking up the wrong tree or expecting > something that couch never has plans to support. =A0I was expecting that = couch > was going to support authorization on all levels prior to 1.0 and under t= he > current plans it doesn't sound like view authorization and per document > authorization is going to be supported prior to 1.0 or if at all. > There are > also still issues with the current per-database authorization scheme as > outline above and in another thread. =A0I guess I would just really like = to > know what is going on regarding authorization. I hope you'll find that the current authorization system is acceptable for your needs. If there are edge cases (like Brian is finding with his validate_doc_update's need to know what the db-admin's list contains) I'm happy to address those. I don't think it's worth holding up 0.11 for that stuff, and if there is good code done in this area before 1.0, I'll be happy to work on getting it into 1.0. > =A0Feature x and feature y > really shouldn't prevent a 1.0 release. =A0I would love a few things that= have > been talked about, but I think I could hold off on those things until aft= er > 1.0. =A0 I know that couch will never be perfect and 1.0 will need to com= e > soon, but the deficiencies outlined here seem like critical items that I > can't believe would be left off from a 1.0 release. =A0I am at a crossroa= ds > with a few applications that I had planned on started soon and the answer= s > the the following questions would really help me decide if couch was righ= t > or not: > > 1) Is native authorization important to everyone or is running a reverse > proxy considered the preferred solution? This really depends. I'd say most CouchDB installations are not talking directly to the browser. This is due to the missing ACL features. Now that we have some sort of access control (instead of none) I think this will change. > 2) Is native authorization for views on the roadmap? =A0If not, why? If s= o, > what is preventing it from being implemented? (I would like to know if th= e > problem is related to lack of people working on it or if it's actually a > difficult problem to solve.) It is not on the roadmap. I used to want the feature but Damien convinced me that a similar feature was an ongoing security nightmare in Lotus Notes. > 3) Is native authorization for documents on the roadmap? If not, why? Is = so, > same as above? Not on the roadmap -- same reasons. > > I appreciate everyone's work and time here. I understand this is open sou= rce > software and I am really thankful for everyone's work and that couch exis= ts. > I am a huge huge fan. =A0I am really not trying to be difficult or sound = like > an ass, but this just seems like a huge deal to me. Thanks for the note. I think a big part of the perspective I have around access control is this: Couch will be everywhere (eg on everything with an http stack). So if you have secret data don't put it in a public database, keep it in a Couch that you control. If you have complex groups that you want to have access to some data, put it in a database and give only group members access to that database. If you have complex data-control needs, the best way to address them is with replication. If you give each user a personal database, then you can replication only docs they have access to to their personal databases. I know this doesn't solve 100% of everything, but I think it can solve the majority of use cases. I know what we have isn't perfect, and I'm willing to help people with patches (there are a couple of ideas from Brian Candler that I'd like to implement). I don't think we want to hold 1.0 until everything is perfect. The majority of users are more concerned with storage and view stability and performance, which are definitely ready for 1.0. I'd like to make access control as awesome as possible, but I'll live if some parts of it don't make it until 1.1 Chris > > Thanks, > > James Hayton > > -----Original Message----- > From: Damien Katz [mailto:damien@apache.org] > Sent: Friday, February 05, 2010 5:36 PM > To: dev@couchdb.apache.org > Subject: Getting to 1.0, Time for 0.11.0 + Feature Freeze > > Hello CouchDB contributors! It's time to do a 0.11.0 release, which shoul= d > be the last release before 1.0. > > I know lots of people have particular features they want before we hit 1.= 0. > but that will always be true. I can list 3 things I wish we had, but I'm > willing to live without them for now so we can push ahead. > > I propose we create the 0.11.0 branch, and that will eventually become 1.= 0. > New features will continue to go into trunk. Also new features can still = go > into the 0.11/1.0 branch, but they will need consensus from the community > from this point on. > > If the community generally agrees, I'd like the branch created monday. If > you have objections, please air them now. > > -Damien > > --=20 Chris Anderson http://jchrisa.net http://couch.io