[Web-SIG] daemon tools

[Jim Fulton]

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:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org