On Mar 3, 2007, at 6:19 PM, Robert Brewer wrote: > Jim Fulton wrote: > > For some time, Zope has used a daemon-management tool > > we wrote called zdaemon: > > > > http://www.python.org/pypi/zdaemon > > > > Ironically, this sort of tool isn't Python specific at all, > > and the discussion highlighted some non-Python tools, notably > > daemontools and runit, neither of which seemed as appealing > > as zdaemon for various reasons. > > The user interface isn't Python-specific, but the interaction with > WSGI servers, middleware, applications, and frameworks should be. I don't think we are talking about the same thing. See my comment at the end of this note. > Components at all levels of the WSGI stack need to interact with > "site-wide" events and settings. What I'm envisioning (and writing > for CP at the moment) is a framework-neutral, one-per-site Engine > object that is basically a publish/subscribe messenger; when you > import a Python web framework, it registers listeners for process > start, stop, and graceful restart. These would be things that need > to happen regardless of the OS process invoker: whether a common > 'webctl' script (that we author), or a framework-specific function > (like cherrypy.quickstart), or Apache (via mod_python). I encourage you to look at the zope event system which already supports this use case:
http://www.python.org/pypi/zope.event http://www.python.org/pypi/zope.component#handlers > The pub/sub model also supports plugins with their own channel(s). > For example, frameworks would blindly call engine.publish > ('autoreload.add', filename) as desired. If the invoker (webctl, > quickstart, or Apache) plugs in an autoreloader, great; it > subscribes to that channel, receives each message, and adds each > filename to its list of files to monitor. If no autoreloader has > been plugged in, the 'add' message is correctly ignored. And when > the autoreloader detects a change, it would also publish 'reload' > or 'reexec' messages, which would then be subscribed to by a Reexec > plugin. Most of the plugins would be provided by the invoker, but > frameworks would be free to use the Engine to register their own > events and event listeners. > > This interface between a site-wide container and the WSGI > components is far more important to me than the actual details of > invocation (like forking, signal-handling, logging, etc). The > latter can be written as Engine plugins, and can compete in a > market created by a good "Web Site Engine Interface" spec. I think you're "sitewide container" is the main program that loads the WSGI components. This might be Apache, if mod_python is used, or some Python script/program. I was discussing a tool that managed the main program in the later case. Something that started and restarted it, provided status information, helped it to run as a proper daemon and so on. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ 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