couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: CouchDB Cluster/Partition GSoC
Date Fri, 03 Apr 2009 20:30:46 GMT
On Fri, Apr 3, 2009 at 11:42 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> Just wanted to make it available to everyone to see now, in case you're
> curious, even though review/comment time is past.
>
> I meant to get this out earlier to allow some review time, but I just got
> buried too deep in academics this week.
>
> The proposal has been officially submitted, but you need a GSoC site account
> to view it, so here's the public document that contains the same info:
> http://socghop.appspot.com/document/show/user/rleeds/couchdb_cluster
>
> For those with an account, the submitted proposal is here:
> http://socghop.appspot.com/student_proposal/show/google/gsoc2009/rleeds/t123878289629
>
> I'm not terribly concerned if the details aren't all there, as long as the
> proposal itself is convincing enough. The plan includes much discussion and
> hashing out of the details... i.e. more of the discussion in this thread
> along with some profiling and planning before execution of the nitty gritty
> stuff happens.
>
> Thanks for all the advice and help

>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.

> 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)

Hope that helps,
Chris

-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message