On Jun 26, 2007, at 1:04 AM, Graham Dumpleton wrote: > In Apache changing the certificates would need a complete restart of > everything. Because the child processes aren't privileged they would > not be able to trigger the main server to do so. This actually gets to > one of my reservations about some of the stuff being discussed. That > is, that the WSGI applications should even have any ability to control > the underlying web server. In a shared web hosting environment using > Apache, allowing such control is not practical as you don't want > arbitrary user doing things to the server. If you are running Apache > as a dedicated server for a single application that is a different > matter however. Thus some aspects of what can be done by via the bus > would have to be controllable dependent on the environment in which > one is running. > > At least with Apache, even initiating this sort of stuff from inside > of a WSGI application may not make a great deal of sense even then. It > would be far easier and preferable in Apache to use a suexec CGI > script to accept the upload of the SSL certificate and then trigger a > restart of Apache. So in the end the bus concept may be great for pure > Python system, but not so sure about a complicated mixed code system > like Apache, especially where there may be better ways of handling it > through other features of Apache.
There are also non-webbish processes like postgres, mysql, etc. that need to be treated as "part of the application". I handle this currently by running all of the processes related to a specific project under a process controller (which happens to be implemented in Python, but that's besides the point, see http:// www.plope.com/software/supervisor2/). The process controller is responsible for execing the child processes upon its own startup. It is also responsible for restarting children if they die, capturing their output (if any), and allowing sufficiently privileged users to start and stop each one independently. The only promise a subprocess must make to be managed is that it must be possible to start the process "in the foreground" (not under its down daemon manager). If a "process bus" is implemented I suspect it should be implemented at this kind of level. "Actions" could be registered for a specific subprocess types to send some input to a pipe file descriptor, send a signal to the process, etc. It would also be possible to create some sort of dependency map between processes in a configuration, that relate the actions of one process to another (restart process A if process B is restarted, send a signal S to process C if signal T is sent to process D, etc). - C _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com