CouchDB and Erlang

[Robin B <ro...@gmail.com>]

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

Re: CouchDB and Erlang

[Noah Slater <ns...@apache.org>]

On Fri, Apr 18, 2008 at 12:42:14PM -0500, Robin B wrote:
> REST and JSON are great for certain situations, but they should never
> be hard coded into the datastore.

I disagree with this FWIW.

REST is, quite fundamentally, a software architectural style, and one which
brings it's own set of high level abstractions. It's not an implementation
detail to be further abstracted away behind some public API.

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

Not sure who you were quoting here, but it's a bit misleading.

Lucene is not a dependancy, and to some extent neither is SpiderMonkey. ICU is
the only library that CouchDB requires and your suggestions would not do
anything to change that situation.

I am, however, in favour of a plug-in type system at some point.

-- 
Noah Slater - The Apache Software Foundation <http://www.apache.org/>