[Web-SIG] Web Site Process Bus

[Robert Brewer]

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
fumanchu at amor.org