couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Hayton" <theb...@purplebulldog.com>
Subject RE: Getting to 1.0, Time for 0.11.0 + Feature Freeze
Date Mon, 08 Feb 2010 21:54:45 GMT
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: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 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


Mime
View raw message