couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McDaniel <>
Subject Re: Google Summer of Code
Date Tue, 10 Mar 2009 19:23:22 GMT

Subject ID : couchdb-erlang-interface

Title      : Erlang interface to CouchDB to bypass HTTP/JSON layer

Keywords   : Erlang, CouchDB, interface

 This work would provide a direct interface to CouchDB.
 It could be used by, e.g., wpart_* interfaces from Erlang-Web,
 or by appmods in YAWS.  It would interface directly to the
 CouchDB Erlang layer using Erlang term(), not JSON conversions.
 There would be no HTTP involved, only direct Erlang message
 passing or fun calls to/from CouchDB.  If a message passing
 design is used, distributed access to one or more CouchDB nodes
 may be simplified (e.g. a cluster of web servers accessing
 one or more CouchDB nodes).  Interface should minimally 
 provide same functionality as that available to view servers
 or via HTTP interface and allow for maintenance to keep
 parity when new functionality is added.

 Since modifications/additions of CouchDB source is involved,
 additional value could be added by providing another interface
 to couch_query_servers which can pass lists of documents
 rather than a single document (to view servers and via the
 Erlang interface).  This would allow parallel map functions
 to run on subsets of the list provided by couch_query_servers.
 couch_query_server could dynamically check memory and adjust
 the number of documents sent.


On Tue, Mar 10, 2009 at 07:51:29PM +0100, Jan Lehnardt wrote:
> Hi,
> I started collecting proposals on
> Can you help out adding a few more form this thread, that'd be nice,  
> thanks :)
> Cheers
> Jan
> --
> On 3 Mar 2009, at 13:06, Jan Lehnardt wrote:
>> Hi dev@,
>> last year, we missed the Google Summer of Code* application
>> deadline by hours (my fault). This year, applications run on
>> March 9th-13th.
>> *
>> GSoC provides an excellent opportunity for open source projects
>> to get students involved with the project and have larger areas of
>> functionality covered.
>> What is needed from our end (roughly, see the rest of the GSoC
>> FaQ*** for more info)?
>> - A single person as an administrative contact. I volunteer for this
>>   position if nobody else is eager to take it.
>> - A "list of ideas"** that includes a number of sub-projects that  
>> students
>>   can apply for when working on CouchDB. This is where you come
>>   in! :) What feature of CouchDB would you like a student to work on
>>   during the summer?
>> - A vote on which student-proposals to accept.
>> - Once we have one or more students with an idea each, we'll need a
>>   mentor for each sub-project.
>> ** From the GSoC FaQ***:
>> An "Ideas" list should be a list of suggested student projects. This  
>> list is meant to introduce contributors to your project's needs and to 
>> provide inspiration to would-be student applicants. It is useful to 
>> classify each idea as specifically as possible, e.g. "must know  
>> Python" or "easier project; good for a student with more limited  
>> experience with C++." If your organization plans to provide an  
>> application template, you should include it on your Ideas list.
>> Keep in mind that your Ideas list should be a starting point for  
>> student applications; we've heard from past mentoring organization  
>> participants that some of their best student projects are those that  
>> greatly expanded on a proposed idea or were blue-sky proposals not  
>> mentioned on the Ideas list at all.
>> ***

View raw message