couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastian Cohnen <>
Subject Re: Replacing the _external API
Date Fri, 24 Sep 2010 18:54:38 GMT
Does your proxy imply http or tcp? I'm thinking about unix sockets, which would be awesome
for many kinds of applications.

On 24.09.2010, at 20:10, Paul Davis wrote:

> At CouchCamp there was a bit of discussion on replacing the _external
> API with something a bit more modern to give _external processes more
> control over their environment.
> The idea was born out of a discussion with Robert Newson who mentioned
> that couchdb-lucene really only needs a reverse proxy to put itself in
> the same URL namespace. It occurred to us that having a reverse proxy
> instead of the current _external stdio protocol would allow lots of
> other interesting features like node.js integration, as well as allow
> implementors to handle requests in parallel and so on and such forth.
> The major drawback that was identified was that if we switched to just
> a reverse proxy, people would then be responsible for handling the
> process management of their _external handlers. Ie, they'd have to
> configure daemon monitoring to make sure the processes stayed up and
> what not. The solution we came up with was to include another feature
> that did process management. Ie, something that would bring up an OS
> process when the server booted, and respawn it if it crashed. There'd
> be no connection to the _externals. Other than the basic "just keep a
> process up" sort of behaviour, the only other thing I could see adding
> is a simple stdio protocol to get configuration values from CouchDB.
> Other people have expressed interest in just the process management
> functionality as well which makes me think that having the two new
> features to replace the _external API would be both easier on
> developers as well as providing more functionality.
> So now I'm looking for feedback on what other people might think of
> this. I'll start working on this fairly soon if I don't hear any major
> objections.
> HTH,
> Paul Davis

View raw message