couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: os_daemons and query_servers
Date Thu, 27 Jan 2011 00:52:20 GMT
On Wed, Jan 26, 2011 at 7:03 PM, Norman Barker <> wrote:
> Paul,
> understand the answer is no (currently), then why?

As Randall says, the protocol between the two types of OS processes is
quite different. Each protocol is generally a request/response type of
protocol, except the actors are switched. In the view server code, it
is Erlang making requests to the OS process, and for os_daemons, it is
the OS process that makes the request. Interleaving the two would
undoubtedly cause more headaches for both the Erlang implementation
and anyone wanting to write an OS process that implemented one or both

That said, there's not really a whole lot of code in regards to os
daemons. I think you'd be hard pressed to find examples of where we
could share code between the two processes without overgeneralizing
functions to the point where they're harder to reason about. The
entire os_daemons module [1] (which is almost entirely self contained)
weighs in at 364 lines (total, not discounting blank lines or

> a view server can be an external process, python for example, so now
> we have two external managers within couch, why? Why fix a bug in two
> places (I am verifying a timeout bug with the query_servers for an
> external process).

I will give you five internets if you show me a timeout bug that
exists in both the os_daemons code and view_server code.

That said, the os_daemons code was written after the initial view
server implementation using a couple paradigms that I've learned since
last hacking on the view managers. There are definitely bits we could
port back to the view server manager to simplify a lot of logic.

> Is combining os_daemons with external query_servers worth doing, if I
> do this and add a patch can I get this into the trunk?

If you wrote something we would of course consider it. Although,
perhaps I'm too close to this code but I can't really see a way to
combine these two features into a single implementation that wouldn't
magnify the complexity somewhere, either in CouchDB itself, or inside
the external processes.

On the other hand, the view server code is in desperate need of a make
over. Adam and I have made attempts independently but neither of us
has committed anything.

> thanks,
> Norman


View raw message