[Web-SIG] daemon tools

[Robert Brewer]

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
fumanchu at amor.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20070303/be2a01b8/attachment.html