On Wed, Jan 26, 2011 at 16:03, Norman Barker <[email protected]> wrote: > Paul, > > understand the answer is no (currently), then why? > > 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).
The essential difference between the two is the direction of request/response flow. With a synchronous line protocol this communication must be initiated by one side or the other. With query servers, couch initiates: "Prepare these functions", "Map this document" and "Perform this reduce" are examples of requests couch will send. os_daemons have limited ability to request information from couch and they initiate. "Restart me if configuration section <section> changes" is one (the only?) example. Basically, couch doesn't care what the os_daemon process does. If an os_daemon wants to communicate with couch it should use the HTTP interface. Paul's example of an updater notifier would do this by requesting /_changes like any other client. > > 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? > The protocol would have to change to support combining the two completely. Since the query server API must be preserved between minor revisions, this could hit 2.0 at the earliest. Rather than combine the two, perhaps look for patterns/utility functions that are or could be common to both and abstract that into a third module. I would be +1 on any patch which does this without changing the behavior of either. Randall
