couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Replacing the _external API
Date Fri, 24 Sep 2010 18:34:35 GMT
On Fri, Sep 24, 2010 at 2:26 PM, Norman Barker <> wrote:
> Paul,
> for us, the process management is critical, we have external process
> code and due to this process code size and age it is possible that it
> may crash (this is not that unusual!), so I am +1 on process
> management and am interested in helping.

Yeah, Mikeal's first concern when I mentioned replacing _externals was
having the process management so that we can keep the dead simple
slave process semantics. In talking with him we realized that this
would provide a dead simple way to hook up a node.js handler as well,
so I think the idea has legs.

> As for reverse proxy is this going to be inside couch (well inside
> mochiweb) or a process in front of couch and external processes?
> This will add the capability for streaming results from external
> processes so I am +1.

The current plan is to make it inside couch using mochiweb and
ibrowse. I know that BenoƮt had patches land in the recent ibrowse
release for similar reasons so we should be ready to go on those

> Norman
> On Fri, Sep 24, 2010 at 12:10 PM, 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