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. 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. 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.) 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. 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? 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.) 3) Is native authorization for documents on the roadmap? If not, why? Is so, same as above? 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, James Hayton -----Original Message----- From: Damien Katz [mailto:dam...@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 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
