couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: roadmap 0.11/1.0
Date Sun, 01 Nov 2009 18:48:25 GMT
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

  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.

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.


  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.


  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.



On Sun, Nov 1, 2009 at 7:02 AM, Benoit Chesneau <> wrote:
> was sent on user@ sorry for crossposting .
> ---------- Forwarded message ----------
> From: Benoit Chesneau <>
> Date: Sun, Nov 1, 2009 at 3:44 PM
> Subject: roadmap 0.11/1.0
> To:
> Hi all,
> hasn't been updated. And in
> fact i'm really curious. What is the next things on the roadmap ? Also
> damien spoke in june to have a fixed release schedule (one every 6
> months ?) is it still something in view ?
> - benoit

Chris Anderson

View raw message