[Web-SIG] Web Site Process Bus

[Phillip J. Eby]

At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
>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.

I have some more basic questions...  like, how do you know you need 
to subscribe in the first place?  Who does the subscribing?

My initial reaction is that I like the general idea, but the idea of 
having a bus *object* seems wrong to me somehow.  Perhaps because the 
only way to get it seems to be in an already-running application, 
which seems to sort of defeat the purpose.  But maybe my purposes are 
different than yours?

Perhaps if you could present some example scenarios to show how you 
see this actually being used...?