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 [EMAIL PROTECTED] _______________________________________________ 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