[Web-SIG] daemon tools
jim at zope.com
Mon Mar 5 12:28:15 CET 2007
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:
> 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 Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Web-SIG