Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 21 Apr 2009 12:30:48 +0100
From: Noah Slater <nslater@apache.org>
To: user@couchdb.apache.org
Subject: Re: Building Erlang app around CouchDB
Message-ID: <20090421113048.GC9728@tumbolia.org>
Mail-Followup-To: user@couchdb.apache.org
References: <f6508a860904210416m18f5852fjdab6f0569162206b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f6508a860904210416m18f5852fjdab6f0569162206b@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)

On Tue, Apr 21, 2009 at 09:16:37PM +1000, David Mitchell wrote:
> I want to be able to build an application around CouchDB that lets me load
> in XML documents (i.e. converting XML to JSON within Erlang, rather than via
> e.g. a Rails application talking to CouchDB).  I also want to be able to
> extract data from CouchDB as XML documents, again doing all the JSON<->XML
> conversion within Erlang rather than a separate language.  The whole thing
> should work as a Web service (either REST or SOAP would be fine, although I
> imagine REST should be easier as CouchDB itself has a REST interface).

This sounds like a good opportunity to work with the grain of CouchDB and HTTP.

  By eschewing shared state, and enforcing a uniform interface, we restrict
  components from “seeing” beyond the context of an individual request. This
  introduces a “pipe and filter” style property to the system, where access or
  functionality can be added, modified, or restricted transparently between
  client and server.

  Common features such as authentication, authorization, caching, compression,
  partitioning, proxying, tunneling, encryption or URI rewriting are possible by
  placing standard applications such as Apache httpd or nginx in front of your
  server. You’re free to augment, adapt or limit your setup as you see fit.
  Figure 1-7 shows an example configuration of layered Web architecture.

  Need some caching? Just throw in a cache between your server and clients. Need
  some load balancing or authentication? Just throw in a reverse proxy.

      - Layered System, CouchDB: TDG, http://books.couchdb.org/relax/why-couchdb

Need media type conversion? Throw in a proxy!

  Intermediary components act as both a client and a server in order to forward,
  with possible translation, requests and responses. A proxy component is an
  intermediary selected by a client to provide interface encapsulation of other
  services, data translation, performance enhancement, or security protection.

        - http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

See Figure 5-10, ibid.

Best,

-- 
Noah Slater, http://tumbolia.org/nslater