[Web-SIG] Web Site Process Bus (re-send)

[Phillip J. Eby]

At 02:47 PM 6/25/2007 -0700, Robert Brewer wrote:
>If I'm primarily a Pylons user, I'm used to starting my websites with
>"paster serve". In this case, paste.script would create a WSPBus object.
>[It's up to the Paste developers whether to distribute their own
>wspbus.py module, or to require one via setuptools.] When Paste parses
>the paste.deploy file and composes the WSGI stack, it somehow hands a
>Bus reference to Pylons. Exactly how is up for debate; Pylons might
>provide a hook for it (say, in app_globals.py), or Pylons components
>might take the bus as a constructor arg.
>
>Paste's ServeCommand object would load the WSGI components and server
>(as it does now), but then, instead of calling server(app), it would
>call bus.subscribe('start', server, app). Pylons and Zope would also
>have the opportunity to subscribe listeners to the 'start' channel (and
>other channels), such as database connections, access log files, etc.
>Then, instead of calling server(app) directly, Paste would call
>bus.start(). It could then call bus.block(states=states.STOPPED) instead
>of trapping KeyboardInterrupt itself. If block() traps a KBInt or
>SyExit, it sends the 'stop' message to all subscribers, regardless of
>whether they were created by Paste, Pylons, or Zope. They all shut down
>synchronously, and then Paste could feel much safer about calling
>bus.exit(). If KBInt or SysExit are trapped by a Pylons or Zope
>component, they would be expected to call bus.stop or bus.exit (which
>would unblock Paste).
>
>If I'm primarily a Zope user instead, I might start my website with
>zdaemon. This would work exactly like the above, but the Bus object
>would be instantiated and started by the zdaemon package. If I'm using
>Graham's new mod_wsgi with Apache, I might expect it to create and
>control the Bus.

I sort of understand the above scenarios -- except the part where the 
bus is actually doing anything useful.  What is it that you get that 
you can't do almost as easily some other way?

(The other piece that throws me is the idea of using block to *run* 
the main process.  Huh?  Where's the event loop then?)


>If I'm using paste.script but I want autoreload to use execv instead of
>the default child-process style of autoreload, this is much easier with
>the WSPBus. Instead of hacking paste.script, I unsubscribe Paste's
>default autoreloader from the 'restart' channel and subscribe my own.

This sounds like something useful, or it would if I had any use for 
code reloaders, which IMO are more appropriate for a development 
environment than a production one.  Nonetheless, I'm not sure it 
deserves an entire event bus specification just to be able to have 
pluggable autoreload.  :)