Phillip J. Eby wrote: > 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...?
I'm also confused about what this is about. Or maybe it feels like it's about more than one thing, and needn't be. The blog post kind of helps and also kind of confuses things. For instance, doesn't atexit work fine for exiting? (Not in mod_python, but I still don't know why it *shouldn't* work in mod_python.) Of course, there isn't anything for other signals, and creating something for those would be quite useful. Potentially a Zope-style minimal event framework would work. Maybe something like: send_signal(signal_name, signal_data) subscribe(signal_name, listener) Where in the second case, listener(signal_name, signal_data) is called, and signal_name can be used to automatically filter, or None to receive all signals. I prefer strings for the names, because then there's no dependencies (you don't have to import anything, you just have to have packages agree on names). I think Zope doesn't have any high-level filtering (?) and generally uses interfaces for filtering in the listener itself. Anyway, given that we still would need to define the signals we care about in the web context, but it's not too terrible hard I think. Maybe the "bus" you are talking about that is registered is the thing-that-sends-signals? I think it can simply be a single module/library that we all agree to use. Anyway, this mostly seems like what you are describing. I guess when viewed as an event publishing system, there's other concerns that pop up -- can you cancel the event? (Ugh, I don't think so; I think GUI events and signals are something fairly different from what we're talking about here). Also, should exceptions propagate? I feel vaguely like they should, but I'm not sure. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers _______________________________________________ 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
