couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Getting to 1.0, Time for 0.11.0 + Feature Freeze
Date Mon, 08 Feb 2010 22:29:14 GMT
On Mon, Feb 8, 2010 at 1:54 PM, James Hayton <> wrote:
> 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.  Well, maybe that depends on what everyone
> considers to be a new feature.  I 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.  If the remaining work to be done regarding authorization is
> considered a new "feature" then I would definitely be -1 on a feature
> freeze.  I 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 fully
> committing to support and extend the current model.  The work Chris has done
> in trunk is a great step forward, but there are still things missing as far
> 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.  There may be a few other features such as
> http communication, but outside of those two main features I could swap
> couch for mongodb, persevere, riak, etc... and I would probably be able to
> develop most applications just as well as I could using couchdb.  The point
> is there are tons of options in the nosql space and the things that really
> 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.  The biggest
> thing limiting those applications from actually being built is better
> authorization.  I 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 inside
> titanium and serve up an application that contains data for more than one
> user locally.   I don't want to install nginx across 100's of client
> machines.  I want to keep things simple.  Currently my only option would 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 database
> is accessible to all.  There is also the inability to join views from two
> databases, which makes the solution of using separate databases much less
> attractive.  ( 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

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.   Couch is restful and it ideally should be able
> to handle authorization on the database, document and views levels.  In my
> opinion couch is not ready to be released as 1.0 software until it does just
> 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.  I don't want to be barking up the wrong tree or expecting
> something that couch never has plans to support.  I was expecting that couch
> was going to support authorization on all levels prior to 1.0 and under the
> 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.  I 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.

>  Feature x and feature y
> really shouldn't prevent a 1.0 release.  I would love a few things that have
> been talked about, but I think I could hold off on those things until after
> 1.0.   I know that couch will never be perfect and 1.0 will need to come
> soon, but the deficiencies outlined here seem like critical items that I
> can't believe would be left off from a 1.0 release.  I am at a crossroads
> with a few applications that I had planned on started soon and the answers
> the the following questions would really help me decide if couch was right
> 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?  If not, why? If so,
> what is preventing it from being implemented? (I would like to know if the
> 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 source
> software and I am really thankful for everyone's work and that couch exists.
> I am a huge huge fan.  I 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

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


> Thanks,
> James Hayton
> -----Original Message-----
> From: Damien Katz []
> Sent: Friday, February 05, 2010 5:36 PM
> To:
> 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 should
> 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

Chris Anderson

View raw message