On Fri, Sep 24, 2010 at 2:19 PM, Robert Newson <[email protected]> wrote: > Assuming it's straightforward to extend OTP-style process monitoring > to external processes (and I'm assuming that the couchjs processes are > so monitored today) then I like the proposal to add both of these > things. >
Yeah, intend for the process monitoring to behave almost exactly like it does current for _external scripts. Just a "restart when dies" sort of configuration. The config protocol over stdio was a last minute idea to make it easy for implementors to figure out where their couch is and what not. > My obvious motivation is couchdb-lucene so, with that hat on, would > this mechanism obviate the need for start couchdb-lucene externally > and make the Python hook script obsolete? I think it does. Finally, > there are cases where c-l users might wish to locate their c-l server > on a different box, so we should allow the proxying independently of > the launch-on-demand-and-keep-me-running bit. > > B. > They'll be completely separate features for precisely this sort of reason. I haven't quite figured out the details on proxies to external hosts. I see the real need, but I feel as though we should have a method for disabling the external host ability as well. > On Fri, Sep 24, 2010 at 7:10 PM, Paul Davis <[email protected]> > 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 >> >
