From: Loren Stafford [mailto:lstafford@icompression.com]
1. Starting the Dispatcher on Zope start-up. The only place I can think to put this kind of initialization logic is in __init__.py of the product. That code would have to look for any already-created instance and (if found) run it's Dispatcher method in a separate thread. Is there any way to do this? I have a feeling I'm confused on this point. I seems odd for __init__.py to look for instances.
2. Does it make sense to provide for more than one instance of the scheduler? I can't think of a reason. But then you couldn't prevent someone from creating as many as they want, could you?
3. Managing separate threads. Will Zope's persistence and transaction mechanism provide all the mutual exclusion I need on the schedule queue? ...or do I need some kind of lock?
As a little follow-up: It was I who had already started a ZScheduler project, and worked out how to do the architecture, and wrote some initial code. Due to a new job here at DC, I ran out of time for the project completely. I have now however, transferred my ideas to Loren in a private email conversation, including all code I had on the subject. Code included a ZCatalog based scheduler object automatically being created in the root, and 'write-protecting' it (like the standard_html_header, _footer, and _error objects). Also, registering of Event objects was in place. I hereby have handed over my project to Loren to do with it as he sees fit. =) -- Martijn Pieters, Software Engineer | Digital Creations http://www.digicool.com | Creators of Zope http://www.zope.org | mailto:mj@digicool.com ICQ: 4532236 | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 -------------------------------------------