[Web-SIG] Web Site Process Bus

[Chris McDonough]

On Jun 26, 2007, at 2:39 PM, Robert Brewer wrote:

> Chris McDonough wrote:
>> There are also non-webbish processes like postgres, mysql, etc. that
>> need to be treated as "part of the application".
>>
>> I handle this currently by running all of the processes related to a
>> specific project under a process controller (which happens to be
>> implemented in Python, but that's besides the point, see http://
>> www.plope.com/software/supervisor2/).  The process controller is
>> responsible for execing the child processes upon its own startup.
>> It is also responsible for restarting children if they die,
>> capturing their output (if any), and allowing sufficiently
>> privileged users to start and stop each one independently.
>> The only promise a subprocess must make to be managed is that
>> it must be possible to start the process "in the foreground"
>> (not under its down daemon manager).
>>
>> If a "process bus" is implemented I suspect it should be implemented
>> at this kind of level.
>
> Ah, but there's the rub: we all have different ideas about how to
> *implement* IPC and control.

I'm confused by this in your earlier message, describing example  
scenarios:

"""
If I'm primarily a Zope user instead, I might start my website with
zdaemon. This would work exactly like the above, but the Bus object
would be instantiated and started by the zdaemon package. If I'm using
Graham's new mod_wsgi with Apache, I might expect it to create and
control the Bus.
"""

I'm confused because zdaemon is a generic process controller, it  
knows nothing in particular about the application running under it  
except that it's a UNIX process.  It could start postgres instead of  
Zope if you configured it to.  If zdaemon creates a Bus object,  
nothing will be able to send messages to the bus except zdaemon  
itself, and there can't be any useful listeners because it doesn't  
share the same process space as its child.

I think I'm mostly confused by the name "process bus" because it  
seems like the primary use case for something like this is where all  
of the applications share the same process space and are all written  
in Python.  Am I right?  If so, maybe a different name is in order?   
"Application Bus"?  Or even "WSGI Bus", if its presumed that all of  
the applications will be WSGI applications?

- C