From dev-return-3829-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Apr 08 05:42:02 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 84414 invoked from network); 8 Apr 2009 05:42:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 8 Apr 2009 05:42:02 -0000 Received: (qmail 95420 invoked by uid 500); 8 Apr 2009 05:42:00 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 95316 invoked by uid 500); 8 Apr 2009 05:42:00 -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 95306 invoked by uid 99); 8 Apr 2009 05:42:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Apr 2009 05:42:00 +0000 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=HTML_MESSAGE,SPF_PASS,SUBJECT_FUZZY_TION X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of randall.leeds@gmail.com designates 209.85.218.170 as permitted sender) Received: from [209.85.218.170] (HELO mail-bw0-f170.google.com) (209.85.218.170) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Apr 2009 05:41:50 +0000 Received: by bwz18 with SMTP id 18so3014420bwz.11 for ; Tue, 07 Apr 2009 22:41:29 -0700 (PDT) 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=vZpzykncPSSrvkD26oFpWseuItxa4wQdcbTfvuZ+aLU=; b=ceYs5t/DuwU02MXlF9gnBOagHMrQHL0Khb+xyVYWJ5Oq3fPPvLOkhCegA1AvxHpkbw JH7bVpjin7kVuXr/MMAwU0RDOPDbcPg4uRUns+nQ67w5dt4H+1sMAueXq8x24swVRUjt YM+wlIDYYeSx9dRZChVZCvvjVXn8V7PGiji7A= 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=tikuL/q4BroT1PpvScoDbgWanRtmiHke1JWwWqX74sOVAHqxBECKU6yEZJ59rcsGAu vs4qkhGW00rrpRkYyaRzXPBYYQmFVbmcEDuSlxMEu9e6rquQlOCnU/51L27AytKRPZQB Y1TvcP5qR4XTS4J754csn43RaDyRyB32Ow+sE= MIME-Version: 1.0 Received: by 10.204.50.195 with SMTP id a3mr766581bkg.123.1239169289440; Tue, 07 Apr 2009 22:41:29 -0700 (PDT) In-Reply-To: References: <1C84EB8A-EF5D-41EB-B7BD-77F660AB7087@apache.org> <63F56D64-2314-490F-AEA7-FC73E956DD8B@apache.org> <4D05932B-FEA8-4A50-8A0D-C6AD0A8E41B2@sankatygroup.com> Date: Wed, 8 Apr 2009 01:41:29 -0400 Message-ID: Subject: Re: CouchDB Cluster/Partition GSoC From: Randall Leeds To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=001636c5ad0d504efd046704955f X-Virus-Checked: Checked by ClamAV on apache.org --001636c5ad0d504efd046704955f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thanks for the suggestions, Chris. Link is still here: http://socghop.appspot.com/document/show/user/rleeds/couchdb_cluster I can't seem to access the edit page for the official proposal submission right now. I get an error. However, I've done some updates. At this point, I'm hoping that you or Damien might consider picking this up and decide to endorse it and become a mentor. Then it's up to the foundation and Google! Either way, I want to be involved in this work :) Cheers, Randall On Fri, Apr 3, 2009 at 16:30, Chris Anderson wrote: > > From the proposal: > > 2. Fast http proxy writen in Erlang which leverages the consistent hash > for determining destinations > > You might find it simpler to use Erlang messaging instead of http in > the proxy layer. I'm not certain about this but it might end up > simpler and faster in the long run. There are arguments in favor of > http, so I'd say the choice is yours, but keep in mind someone will > eventually attempt the other way, no matter which you chose. Yeah, this is what I had in mind after we talked and I wrote this wrong. > > > August 10 - Submit patches for review, discussion and polishing > > I think it would make for a smoother process if you attempt to > integrate as you go. It'll mean identifying the smallest useful chunks > of work, to get us from here to there, but it's also the open-source > way, and I think it results in better code. Nothing like having what > you're working on being used in real applications. > > Can you identify the very first step? - maybe it's an integration test > in JavaScript that proves that three dbs (on one host) can have > document ids partitioned correctly. (I think a core thing here is > getting the right validation functions on the right db's, so they > reject bad PUTs) I finally got around to a crack at adding some JS test examples. I'd like to add some examples about querying partition setup, etc, but then again, that might just be in the _design doc. There are so many questions unsettled still that I feel like what I added is probably enough to get a feel for it. --001636c5ad0d504efd046704955f--