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

[Robert Brewer]

Phillip J. Eby wrote:
> At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
> >This should be a collaborative effort, and I'm very open to
> >discussion at all levels of detail. Even if this flies at the highest
> >conceptual level, there are still several things I know of 
> >we would need to nail down:
> >
> >  * States. For example, do we need an EXITING state? If so, 
> >we should probably rename STOPPED to IDLE.
> >  * State transitions: do we need to lock or block which Bus 
> >methods can be called, depending on the current state?
> >  * Standard non-state channels, such as signals. Do we want 
> >a 'status' channel (for e.g. zdaemon)?
> >  * Should bus.log take other args, like 'severity'? Should 
> >it assume a stdlib logging API?
> >  * Should bus.log be replaced with separate stdout and 
> >stderr instead?
> >  * ...and just to introduce a bikeshed, is there a better 
> >name for the spec effort than "WSPB"?
> >
> >I have lots of other questions, but I'll let you all ask them.
> 
> I have some more basic questions...  like, how do you know you need 
> to subscribe in the first place?  Who does the subscribing?
> 
> My initial reaction is that I like the general idea, but the idea of 
> having a bus *object* seems wrong to me somehow.  Perhaps because the 
> only way to get it seems to be in an already-running application, 
> which seems to sort of defeat the purpose.  But maybe my purposes are 
> different than yours?
> 
> Perhaps if you could present some example scenarios to show how you 
> see this actually being used...?

Sure. Let's assume I want to have a single host+port serve apps from two
different WSPB-enabled frameworks; let's use hypothetical future
versions of Pylons and Zope.

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.

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.

I'll stop there for now.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org