couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: roadmap 0.11/1.0
Date Mon, 02 Nov 2009 06:31:25 GMT
On Sun, Nov 1, 2009 at 7:48 PM, Chris Anderson <> wrote:
> Thanks Benoit for the topic,
> I've got a wishlist for 0.11 / 1.0 - some of it I'd be game to
> implement, some of it I think others would be better suited for:
> Accounts tab in Futon
Not a big deal. Having real authentification would be more
interresting imo. Currently user db is accessible to anyone and we
can't forbid read. It's really difficult to use couchdb in a non
trusted environment as-is. DIY is not good when we speak about
authentification/security and if anyone do it in its corner it soesn't
help. Also couchdb behind a proxy isn't a solution on a local machine
shared by users.

>  Eventually we'll need something like /_utils but not for developers.
> For now we just need a page in Futon where you can login and out, as
> well as manage user accounts if you are an admin.
> Listable _changes
>  If you could format the changes feed with a _list style API, you
> could use it to drive XMPP or other protocols. I'm keen on building a
> version of Toast chat that works even in browsers that have JS
> disabled. I have a feeling the only person who's gonna write this
> patch is me.

Is this related to filtered changes or that would be a continuous view
update ? Also I think having filters working on continuous/longpoll
_changes is important too. Currently continuous filtered _changes
don't work and we have to filter on client side which is not very

> couchjs security
>  The couchjs process is currently "secure enough" for the context
> where only admins can modify design documents. However, as CouchDB
> spreads, we're sure to see misconfigured instances out there. Also,
> making the JS capabilities more controlled will definitely protect
> against some attacks in shared hosting environments. (Eg those where
> many users have private dbs on the same node.)
>  Currently JS functions can hack the sandbox to make http requests
> via curl. We need this functionality for the test suite, but not for
> the design document OS process. So we should use a command line flag
> to --enable-http that the test runner can use.
>  We can also be more secure in our ["reset"] handling. Because
> there's no such thing as a real JS sandbox, if we move our ["reset"]
> handling to C, and have it swap out the JS context for a new one,
> we'll avoid the case where databases on the same node can spy on each
> other, by say, overwriting the emit() function to also store important
> values for later playback to the attacker db. There could be some
> performance impacts of a C-based reset (as it would involve compiling
> all of main.js after each reset).
>  An alternate way to implement this is just to stop recycling
> processes in Erlang, and through them out after each use. I think that
> will get expensive (but maybe not much worse than C-based reset). This
> is trivial patch if anyone needs to run extra securely in a
> shared-host environment today.
> cron / event / changes handler
>  Applications need to be able to trigger functionality in a periodic
> or event-based way. We could probably piggyback on _changes heartbeat
> to provide cron + event services. The idea is a design document
> function ("event" or "cron" or maybe "trigger") that is called once
> for each item in the changes feed.
>  This is the one I'm least sure about, but I've heard a lot of people
> request it. It's problematic because cron functionality isn't that
> useful unless it has side-effects, which brings the whole sandbox/http
> question up again.

mmm why not putting timers based on events ? In fact haing a function
reacting on different  events could be interresting too (a filter++
with kind of event).

> rewriter
>  There's getting to be a pretty common pattern where people write
> CouchApps and then deploy them behind a rewrite proxy. We've already
> got rewrite patches floating around. It's just a matter of making the
> API decisions.

> clustering
>  I've heard Cloudant has some clustering code, I'd definitely be
> willing to help with integration, and I'm sure there are other people
> who would as well.

> Cheers,
> Chris

One feature I would like too would be the possibility to replicate a
full node easyly. Maybe by having a global _changes handler, there are
some patch without review on jira for that. or maybe another way. The
point is that you can't really rely on continuous replication per db
for all dbs if number db > 1000 to replicate one node to another in a
failover mode. First this is a limit actualy, second it make it
difficult to watch the process and revover in case of failure.
Acutually I use drdb for this, but having the possibility to setup
couchdb "slave" would be more portable. We shouldn't have to rely on
the operating system or fs to do that.

- benoit

View raw message