Phillip J. Eby wrote:
> Sent: Monday, June 25, 2007 3:09 PM
> To: Robert Brewer; web-sig@python.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
[EMAIL PROTECTED]
[1] http://www.cherrypy.org/browser/trunk/cherrypy/restsrv/win32.py
_______________________________________________
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
