From dev-return-7094-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Nov 02 06:31:48 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 12224 invoked from network); 2 Nov 2009 06:31:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Nov 2009 06:31:48 -0000 Received: (qmail 38472 invoked by uid 500); 2 Nov 2009 06:31:48 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 38386 invoked by uid 500); 2 Nov 2009 06:31:47 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 38376 invoked by uid 99); 2 Nov 2009 06:31:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Nov 2009 06:31:47 +0000 X-ASF-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com designates 209.85.160.56 as permitted sender) Received: from [209.85.160.56] (HELO mail-pw0-f56.google.com) (209.85.160.56) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Nov 2009 06:31:45 +0000 Received: by pwi18 with SMTP id 18so1881409pwi.35 for ; Sun, 01 Nov 2009 22:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HyIg7bzBOx6TpWAGvQUm7o/7gRBMGmgVFPBv8Z3HMmA=; b=WX0TvIVmhR8AG4TYdMDy//vPfGg04fPzD45aZQOP44dDHpjW/HuRfjZ8jwaIKfYaxR TNeDWHE+QFKHuJBpb8VdDHdyjqv9H5JzucsOfoeDxfOWAnx0Ab2vnbH6/Crmk0TIEeGJ DnxgbVSsFzwglXkUU59RQFSfcWVA9Rt2WapDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IPw1g2dQtz9KAgWFgoX3nX9VZLtHfH7RZaRe7TcPzz3d13TE6H35s4cYQYVmVP7hay 5xu+PmHYl2X+uGc1u6rArwStcCxas+uOvHdoQEZ1Aj0V7zuhooAfQIaFjV3J5Xa1ouRI M6a4FVMNd4hgsMb2OhSJF8O4iuxpcWXNvXLJ8= MIME-Version: 1.0 Received: by 10.140.147.2 with SMTP id u2mr231409rvd.209.1257143485151; Sun, 01 Nov 2009 22:31:25 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Nov 2009 07:31:25 +0100 Message-ID: Subject: Re: roadmap 0.11/1.0 From: Benoit Chesneau To: dev@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. > > =A0Eventually 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 > > =A0If 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 optimised. > > couchjs security > > =A0The 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.) > > =A0Currently 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. > > =A0We 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). > =A0An 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 > > =A0Applications 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. > > =A0This 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 > > =A0There'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. > +1 > clustering > > =A0I'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. > +1 > > 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