[Web-SIG] Web Site Process Bus
Robert Brewer
fumanchu at amor.org
Mon Jun 25 19:57:11 CEST 2007
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
More information about the Web-SIG
mailing list