[Zope-dev] Scheduler product, anyone?

[Martijn Pieters]

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 
-------------------------------------------