ZScheduler Version 0.0.7 Date: 2000/07/02

1. Fixed a bug that caused ZEvents to execute in the wrong context.
2. If the action methond of a ZEvent raises an error, a traceback is written in the log.
3. Added a Trigger tab to the management screen for ZEvents.

ZScheduler Version 0.0.6 Date: 2000/06/19

1. Inserted dispatcher.setDaemon(1) in __init__.py so Dispatcher thread terminates when you shut down Zope.
2. Created companion product FrozenLogger to help with STUPID_LOG on Zope ISPs. FrozenLogger has been successfully tested at my CodeIt Computing account.

ZScheduler Version 0.0.5 Date: 2000/06/13

1. Changed Dispatcher to sleep briefly after triggering an event. (It used to just close the transaction and loop back to next event without sleeping. It requires an extra close and reopen of the ZODB connection for each triggering. But now things work better.)
2. Developed on Win98 with Zope 2.1.4. Tested briefly (with success) on the following:

   Win98 on Zope 2.1.6 and 2.2.0b1

   Solaris 2.6 Zope 2.1.4

   Linux (whatever version CodeIt is running) Zope 2.1.3

Use of Python's threading.Event is apparently working properly now (contrary to earlier reports on [email protected]).

Known Problems:

1. If the webserver of the host machine listens on a port other than 80, a "reschedule" operation looses the port number from the URL in the catalog; the rescheduled event cannot then be triggered. This is due to a bug in Zope ZPublisher/Client.py module. (Zope versions through 2.1.6 and 2.2.0b1 are known to have this problem. It should be fixed by 2.2, but it wouldn't hurt to check.) Workaround: Make the following patch to Client.py in two places:

   #headers['Host']=split(urlparse(url)[1],:)[0]

   headers['Host']=urlparse(url)[1]

ZScheduler Version 0.0.4 Date: 2000/03/20

1. Implemented last resort disarming mechanism. Should it happen that the Dispatcher can neither fire nor disarm an event, the Dispatcher itself deletes the event from the schedule.
2. Successfully tested with Zope version 2.1.4 on Windows 98 only. Testing on Solaris has not been successful.

Known Problems:

1. If the webserver of the host machine listens on a port other than 80, a "reschedule" operation looses the port number from the URL in the catalog; the rescheduled event cannot then be triggered. This is due to a bug in Zope 2.1.4 ZPublisher/Client.py module. Workaround: Make the following patch to Client.py in two places:

   #headers['Host']=split(urlparse(url)[1],:)[0]

   headers['Host']=urlparse(url)[1]

2. On Solaris (and perhaps other Unix systems), Dispatcher cannot trigger events. Cause as yet unknown.

ZScheduler Version 0.0.3 Date: 2000/03/09

1. Fixed capitalization error in import of module "threading"
2. Found cause of bug #2 in 0.0.2.
3. Tested with Zope version 2.1.4 on Windows 98 only.

Known Problems:

1. If the webserver of the host machine listens on a port other than 80, a "reschedule" operation looses the port number from the URL in the catalog; the rescheduled event cannot then be triggered. This is due to a bug in Zope 2.1.4 ZPublisher/Client.py module. Workaround: Make the following patch to Client.py on two places:

   #headers['Host']=split(urlparse(url)[1],:)[0]

   headers['Host']=urlparse(url)[1]

2. Should it happen that the Dispatcher could neither fire nor disarm an event, the Dispatcher continues to repeatedly fire the same event. Workaround: none. I haven't seen this condition occur, as long as the patch for problem #1 is applied.

ZScheduler Version 0.0.2 Date: 2000/03/09

1. The ZEvent class is now subclassable by a ZClass.
2. The Catalog View screen now shows the contents of each item.
3. Manual deletion of the Schedule or Schedule items is not catastrophic.
4. Tested on Windows 98 with Zope version 2.1.4 only.

Known Bugs:

1. A "reschedule" operation looses the port number from the URL in the catalog; the rescheduled event cannot then be triggered. Workaround: Don't override "reschedule".
2. Should it happen that the Dispatcher could neither fire nor disarm an event, the Dispatcher continues to repeatedly fire the same event. This can occur due to #1, but I have not seen it occur in any other case. The code which is supposed to protect against such a case is not functioning. Workaround: Don't override "reschedule"

ZScheduler Version 0.0.1 Date: 2000/03/01

The first release. Do not install in a production environment. Published one day after achieving minimal functionality. Lightly tested on Windows 98 with Zope version 2.1.4 only. Missing some robustness features (you could but you should not manually delete the Schedule or Schedule items).