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:49:45 GMT

I think _externals would be deprecated and released after a couple
versions. Is there a specific reason for wanting to keep the stdio
protocol around? As to Erlang externals, I would probably classify
anything running in the same VM as a plugin like what Volker is doing
with GeoCouch.

Also, I don't think that the view server is quite the same metaphor.
The "couch_native_process" is mostly a misnomer that I've apologized
for many times. On the other hand, the idea for "externals" is that
they're always outside the VM, rather than an abstraction for
something inside the VM. If that makes any sense I guess...

Paul Davis

On Fri, Sep 24, 2010 at 2:43 PM, David Hardtke <> wrote:
> Hi Paul,
> Is it possible to support both?  The precedence is query servers, where you
> can define either a stdio based query_server or a erlang/otp based
> native_query_server.  Depending on what you are trying to do,  these
> multiple options come in handy.  In fact, it would be really nice to have 3
> options for externals -- stdio, reverse proxy, and erlang/otp.
> Dave
> On 09/24/10 11: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