Hi, Any chance of seeing native erlang RPC protocol in 11 or soon there after?
Cheers Suhail On Sun, Nov 1, 2009 at 6:48 PM, Chris Anderson <[email protected]> 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 > > 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 <[email protected]> > wrote: > > was sent on user@ sorry for crossposting . > > > > > > ---------- Forwarded message ---------- > > From: Benoit Chesneau <[email protected]> > > Date: Sun, Nov 1, 2009 at 3:44 PM > > Subject: roadmap 0.11/1.0 > > To: [email protected] > > > > > > 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 >
