Graham, thanks for this and the previous post. I've had these issues in mind while designing the current bus, but you raised them far more eloquently than I could have.
Graham Dumpleton wrote: > The only way we may know is to start stepping through specific uses > cases one at a time, not even worrying about the mechanisms of how the > bus may actually work, and discuss what would the intention of each > be. > > > My particular use case for keeping SystemExit around is > > I have an app that allows the user to upload a new SSL > > certificate. Without a restart, or perhaps, given a WSPBus, > > just a drop to IDLE state, the new SSL certificate would > > not be applied to new incoming connections. The thread that > > puts the new SSL Certificate in place needs to be able to > > tell the entire server to reload. > > 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. Right. My expectation was that Apache interfaces (like mod_wsgi and modpython_gateway) would supply custom Bus objects which deny certain behaviors (like calling bus state-transition methods from a WSGI application). I think there's room for Apache site admins to choose whether applications are allowed to do dangerous things, much like how AllowOverride works for .htaccess. > 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. That's not contrary to the bus concept. If there's a preferred way of doing things, then a function can be written to do that, supplied by the site interface, and be subscribed to the appropriate channel. > 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. Cannot those "other features" be comoponentized? The only thing the Bus tries to do is make a common interface for such behaviors--if Apache has native methods to achieve the desired behavior, then great! Wrapping them in bus listeners (and subscribing a safe set of them by default) allows deployers who aren't familiar with Apache to get their site up and running faster. However, mod_wsgi can still use Apache directives for attaching/detaching the listeners if it likes, providing a more Apache-like look-and-feel. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ 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