[Web-SIG] Web Site Process Bus

[Robert Brewer]

I'd like to continue talking about standardization on site-wide process
state and services.

As described more fully on my blog [1], I'm proposing we create a new
spec for a simple publish-subscribe Bus to manage site-wide state
transitions (start, stop, etc.) and connect application components with
site-wide services (daemonize, autoreload, site logging, etc).

This would NOT be a daemon, nor would it introduce any dependencies. It
would simply say that the main program (be it a framework entry point,
or Apache, or a user script) creates a Bus object according to the spec,
and then gives a reference to that Bus object to all participating
components that care about it.

The blog post might seem like I have a finished candidate for this; far
from it. This should be a collaborative effort, and I'm very open to
discussion at all levels of detail. Even if this flies at the highest
conceptual level, there are still several things I know of we would need
to nail down:

 * States. For example, do we need an EXITING state? If so, we should
probably rename STOPPED to IDLE.
 * State transitions: do we need to lock or block which Bus methods can
be called, depending on the current state?
 * Standard non-state channels, such as signals. Do we want a 'status'
channel (for e.g. zdaemon)?
 * Should bus.log take other args, like 'severity'? Should it assume a
stdlib logging API?
 * Should bus.log be replaced with separate stdout and stderr instead?
 * ...and just to introduce a bikeshed, is there a better name for the
spec effort than "WSPB"?

I have lots of other questions, but I'll let you all ask them.


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

[1]
http://www.aminus.org/blogs/index.php/fumanchu/2007/06/24/web_site_proce
ss_bus