On Thu, Mar 5, 2009 at 4:16 PM, Ben Browning <[email protected]> wrote: > A prerequisite for partitioning and a general nice-to-have feature is > an Erlang API for CouchDB. Let's get the discussion going; I'd love to > see an initial version of the API included with the 0.10 release. > > The API will overlap quite a bit with the code in couch_http_db.erl, > couch_http_view.erl, etc. I propose refactoring this code into the > Erlang API methods and having the couch_http_*.erl files use the > Erlang API. This helps us reduce code duplication and will allow us to > test the Erlang API with the existing HTTP tests.
I'm not sure having the HTTP wrapper use the API is the best plan, as it might turn out to be indirection for indirections sake. If it turns out to be simpler to use the Erlang API, then of course lets do, but if it is slower or more confusing, than we shouldn't feel like we have to. > > For the initial version of the API, I'd prefer to only expose a subset > of the HTTP API. Document CRUD methods are an obvious one and at least > a basic form of view queries would be nice. The Erlang API needs to be > just as stable, if not more stable, than the HTTP API - I'm open to > implementing more or less pending reasonable discussion. +1 to keeping it limited to document CRUD on the first round. View queries will be harder to model as they rely on sending side-effects out the HTTP socket (maybe replace http socket with gen-server reply?) Internally, all database operations are updates, and they are all bulk (sometimes with bulk size of 1). I'm not sure how much we want to hide this from the user. It might be better to keep the API wrapper thin, so the user sees this. Then we can potentially add wrappers so you don't have to remember what the structure of a delete is, for instance. Chris -- Chris Anderson http://jchris.mfdz.com
