couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Updating the CouchDB roadmap
Date Sat, 19 Dec 2009 09:33:15 GMT
On Sat, Dec 19, 2009 at 9:08 AM, Chris Anderson <> wrote:
> On Fri, Dec 18, 2009 at 9:02 AM, Noah Slater <> wrote:
>> On 18 Dec 2009, at 16:45, Dirkjan Ochtman wrote:
>>> That said, it's perfectly alright if there's no roadmap at all, I'm
>>> just surprised by the lack of thoughts from the core developers (who
>>> are usually the ones to have these ideas) in this thread.
>> Three of the core developers have been busy attending to real life for the last few
weeks. :)
> Heh,
> Mostly I've been dealing with real life by buckling down and writing code.
> I wrote up my ideas for 0.11 / 1.0 in this thread Nov 1st:
> Re-reading it they are still features I'm interested in, although I'm
> much less ambitious now. What I'd really like to see for 0.11:
> Account's tab for Futon:
>  There's no reason app developers should have to write user account
> code or login/logout code. Users should just be able to log in and out
> of CouchDB (and sign up for accounts) via something like a Futon page
> that ships with the db. The userCtx is already available to Ajax apps
> via /_session so once we have a reliable way to log in and out this
> will be useful.
Maybe we could also make the auth really useful when you don't access
to CouchDB behind a proxy. My plan about this is :

- having authentification a little more modular than it is : cascading
across authentification modules and also add authentification via a
- authorization: having a way to protect read/write(so delete too) on
a db for a list of users or roles
- Protect access to the user database. Having it readable by public
isn't good for security purpose. Regardless of the length of the key
or the algorithm used, there will be a time where it isn't enough. Imo
we should hide access to this db behind an api.

> Design Doc Refactor:
>  I've been heads down working on this patch in my spare time for the
> last 3 weeks. It is 90% a pure refactor (cleanup code not add new
> features.) It is nearing completion. This will change the query server
> protocol but not the HTTP API. You can look at what I've got here:

What will be the changes in protocol ?

> Query Server Security:
>  I haven't started on this yet but my plan is just to work from
> to make it more clear
> when the curl bindings are available to the JS sandbox. If anyone will
> pick this up and run with it I will jump for joy.
I failed to find the relation with security :) Isn't the point of this
fork to add an http client ?

- benoit

View raw message