On Fri, Apr 3, 2009 at 11:42 AM, Randall Leeds <[email protected]> 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
