[Web-SIG] Web Site Process Bus

[Robert Brewer]

Phillip J. Eby wrote:
> At 02:41 PM 6/25/2007 -0700, Robert Brewer wrote:
> >Phillip J. Eby wrote:
> > > Meanwhile, if you get a start call, you must be starting, 
> right?  So
> > > why worry about the state?  It'd be simpler to just use
> > > "before/during/after" messages the way Twisted does.  Your "block"
> > > example could be replaced by waiting for the "after" 
> message of the
> > > desired state, for example.
> >
> >I just realized I haven't really explained what "start" and 
> "stop" mean.
> >I think you might expect it to mean "beginning of process" 
> and "exit the
> >process". But instead, I'm envisioning a FSM that has an "idle" state
> >in-between process init/exit and "server" start/stop, so 
> that, without
> >restarting the process, you can stop and restart (un/bind the socket,
> >etc) the server components. This should also facilitate a 
> daemon parent
> >process having a single site Bus and starting/stopping child 
> processes
> >that contain the WSGI app and server components, if that's 
> the way you
> >want to compose your site.
> 
> Now I'm really confused.  What is the idle state *for*?

One concrete use case could be a test suite that swaps out applications
between tests without exiting the entire process. But there are other
situations where it's useful. The startup script might need a chance to
run mandatory code in-between stop and exit, or a debugger might stop a
live server (stop accepting connections), run a debug session, fix the
problem, then start up again.

> This seems to imply that you need these states to exist for
> distinct components in a single process -- which would be a
> finer-grained sort of "bus" than has been discussed at this
> point, at least as far as I understand it.

That's not what I had in mind, but I wouldn't be opposed to it.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org