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. 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 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: user@couchdb.apache.org > > > Hi all, > > http://couchdb.apache.org/roadmap.html 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 http://jchrisa.net http://couch.io