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