incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin B" <robi...@gmail.com>
Subject CouchDB and Erlang
Date Fri, 18 Apr 2008 17:42:14 GMT
I have been using Erlang heavily for the last year, and I had some
thoughts on CouchDB.

The core couchdb datastore should export  a stable API along the lines
of ecouch http://code.google.com/p/ecouch/

-export([
        db_create/1,
        db_delete/1,
        db_list/0,
        db_info/1,
        doc_create/2,
        doc_create/3,
        doc_bulk_create/2,
        doc_update/3,
        doc_bulk_update/2,
        doc_delete/3,
        doc_get/2,
        doc_get/3,
        doc_get_all/1,
        doc_get_all/2,
        view_create/2,
        view_update/3,
        view_delete/2,
        view_get/1,
        view_get/2,
        view_adhoc/2,
        view_adhoc/3,
        view_access/2,
        view_access/3
        ]).

The HTTP REST server (mochiweb) would call the stable couchdb API to
implement the HTTP interface.  If someone wanted a DAV interface to
CouchDB, then they would write it by calling the API.
This way people can add whatever interface they need, and the other
interfaces can co-exist.

REST and JSON are great for certain situations, but they should never
be hard coded into the datastore.

Documents are stored as Erlang terms in the datastore, when you read a
document, it is converted to JSON with term_to_json.  If someone
wanted to read XML, they just need to write term_to_xml, and nobody
needs to argue the merits of JSON vs XML because you can have any
format you want.

Views should support Erlang mappers and reducers by default because it
will allow the possibility of quick, concurrent, adhoc views without
spinning up threads.
If you need the overhead of SpiderMonkey, then have the erlang mapper
call out to SpiderMonkey or any other view engine for that matter.
All the examples that I have seen, map simple attributes to keys, and
you do not need the weight of SpiderMonkey to map author_id->key.

>From a dependency perspective, CouchDB is becoming very heavy:
SpiderMonkey, Lucene, ICU ...

If you only need a lightweight, multi-master, scalable, concurrent,
persistent document store then these dependencies could be add-ons.

The core of CouchDB could be lean and mean with minimal dependencies.
The JS views, Auth/Auth, Full text search could be plugins.


CouchDB needs a stable native API, and stable native term format
specification.  From the stable API and term format, people can create
REST/JSON, or DAV/XML or whatever protocol, format, or behavior.

Robin

Mime
View raw message