On Fri, Sep 24, 2010 at 2:28 PM, Stephen Prater <[email protected]> wrote: > As one of the people who wanted the external process management, that's a +1 > from me (if my vote counts.) >
Every vote counts, its how we measure community consensus. > But I like the sound of the reverse proxy protocol for externals too. > > stephen > > On Sep 24, 2010, at 1:19 PM, Robert Newson 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. >> >> 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. >> >> 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 >>> >> > >
