Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 91225 invoked from network); 1 Nov 2009 19:42:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 1 Nov 2009 19:42:55 -0000 Received: (qmail 35107 invoked by uid 500); 1 Nov 2009 19:42:54 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 35029 invoked by uid 500); 1 Nov 2009 19:42:54 -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 35019 invoked by uid 99); 1 Nov 2009 19:42:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Nov 2009 19:42:54 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of suhailski@gmail.com designates 209.85.218.218 as permitted sender) Received: from [209.85.218.218] (HELO mail-bw0-f218.google.com) (209.85.218.218) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Nov 2009 19:42:44 +0000 Received: by bwz10 with SMTP id 10so4118477bwz.35 for ; Sun, 01 Nov 2009 11:42:23 -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; bh=3uk4cOwfroffq7AyYA7wFbdhCSptSuL1ZvQY++6gOEc=; b=g0N2t7sS35wg6wmCs7UNGJY1HRtTMh2Lrm2fSiDzj0ZpaO7hsVOcRTWXQOzUYP6/tJ Rl9FjyW4W2OGOt2sBoSPjpE7NdhEPKqfaN8dtoNOR8nGtCh22YNglRAsEBle/embaELM 7v/k+yQSEuBciNrgSqPtmOxUvingKqx4E+Lgw= 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; b=o8d1rQFyghc1iAj3/XfgLxHhQwXCva5xm+LR5zGqmmUj6gf6uhPD2/6ovnYRm2fwXg za/WOKGZnpRMPqLJbHYChBtodwe1+pk97SshJGjwvgOEJd0YhPwYeF1wfC1nfAb7D/Mb YlVcIV2h/4e982iwvcI6LgDKF3Y5m1ms+rFlw= MIME-Version: 1.0 Received: by 10.204.155.80 with SMTP id r16mr3086783bkw.133.1257104543673; Sun, 01 Nov 2009 11:42:23 -0800 (PST) In-Reply-To: References: Date: Sun, 1 Nov 2009 19:42:20 +0000 Message-ID: Subject: Re: roadmap 0.11/1.0 From: Suhail Ahmed To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0015175cd7ecc56f4f04775475dd X-Virus-Checked: Checked by ClamAV on apache.org --0015175cd7ecc56f4f04775475dd Content-Type: text/plain; charset=ISO-8859-1 Hey Chris, I like hovercraft and it's simple and clean api to talk to couch. Are you talking about clustering over RPC? I know way too little about couch to mouth off like this, working my way to defining a structure for trees and graphs in couch is keeping me busy enough. Cheers Suhail On Sun, Nov 1, 2009 at 7:15 PM, Chris Anderson wrote: > On Sun, Nov 1, 2009 at 11:00 AM, Suhail Ahmed wrote: > > Hi, > > > > Any chance of seeing native erlang RPC protocol in 11 or soon there > after? > > > > This may be part of the Cloudant clustering codebase. I can't speak > for them, but from what I've heard it does inter-node communication in > a native Erlang way. You could probably use this interface as a > primary client interface as well, but what do I know? :) > > Chris > > > Cheers > > Suhail > > > > On Sun, Nov 1, 2009 at 6: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 > >> > >> 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 > >> > > > > > > -- > Chris Anderson > http://jchrisa.net > http://couch.io > --0015175cd7ecc56f4f04775475dd--