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.
and I replied: > That's a possible way to go. My intention was to support both 1) > examination of the state by external components (for operations other > than 'block'--progress meters spring to mind) and 2) restrict > some state > transitions if necessary; for example, make bus.start() do nothing (or > block) unless the state is "STOPPED". Would it be helpful to just re-use the terms that Twisted does (in IReactorCore)? The two structures are very similar: Twisted WSPBus ------- ------ core.running bus.state == states.STARTED stop() stop() 'shutdown' events 'stop' channel listeners 'startup' events 'start' channel listeners run() start() The only big difference being that IReactorCore.run also starts the main loop, but that's assumed to be a separate step for WSPBus. Note that IReactorCore.stop raises an error if not core.running, too. I'll also note in passing that Twisted "during" and "after" triggers log on error but don't crash... Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
