I'd like to continue talking about standardization on site-wide process state and services.
As described more fully on my blog [1], I'm proposing we create a new spec for a simple publish-subscribe Bus to manage site-wide state transitions (start, stop, etc.) and connect application components with site-wide services (daemonize, autoreload, site logging, etc). This would NOT be a daemon, nor would it introduce any dependencies. It would simply say that the main program (be it a framework entry point, or Apache, or a user script) creates a Bus object according to the spec, and then gives a reference to that Bus object to all participating components that care about it. The blog post might seem like I have a finished candidate for this; far from it. 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. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] [1] http://www.aminus.org/blogs/index.php/fumanchu/2007/06/24/web_site_proce ss_bus _______________________________________________ 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