Re: Web Site Process Bus (re-send)

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.  

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com

Phillip J. Eby wrote:
> Sent: Monday, June 25, 2007 3:09 PM
> To: Robert Brewer; web-sigpython.org
> Subject: RE: [Web-SIG] Web Site Process Bus (re-send)
> 
> 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?)

It differs by framework. CP runs the socket-listening event
loop in a
separate thread and blocks the main thread. If you were
running the HTTP
server in the main thread, you'd have to make it the last
subscriber to
'start' and let that block for you (that design isn't in the
example
code on my blog, but it could be done fairly easily).

> >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.  

The point is that *any* site-wide behavior would be
pluggable, of
course, from the site log to platform-specific needs
(daemonization
etc.), to "what does SIGUSR1 do?" These all seem
to me like they'd
benefit from decoupling in order to foster a development
market for
them. The CherryPy trunk even swaps out the entire Bus in
order to use
win32events on that platform [1].


Robert Brewer
System Architect
Amor Ministries
fumanchuamor.org

[1] http://www.cherrypy.org/browser/trunk/cherrypy/re
stsrv/win32.py
_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com