At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote: >Seriously, though, this handles the notification but not the state >machine, which I think is critical to the effort. It also doesn't do any >error-handling for misbehaving subscribers, so not all subscribers are >guaranteed to run if there's an unhandled error in an earlier >subscriber.
Again, it would be really helpful if you could provide some scenarios that show why these things are important. It's not immediately obvious to me that they are. For example, if an error occurs, isn't that an indication that the component is broken? Masking the failure just makes it less likely the component will get fixed in a timely manner. 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. _______________________________________________ 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
