Jerry.Spicklemire@IFLYATA.COM wrote
Loren wrote:
... The crontab would run a Zope Dispatcher which would then dispatch Zope methods that had been scheduled from within Zope. Thus, Zope would acquire cronish capabilities.
Mark Lesh (Mark, care to add anything?) developed an "event processor" (pre-Zope) that had similar requirements. Since it had to run on both DOS and Windows boxes it was done in Clipper, which has the very Pythonish capacity of calling code "objects" stored as fields of a Clipper table!
Zope and a standalone Python event loop can easily pass messages in the form of records in a shared data store, e.g. a PostgreSQL database.
... Do you think it's important to capture output?
Not in itself, but it is certainly necessary to verify successful completion of each event, and those events can involve creation of output. ZODB may or may not be the target storage for such output, but an effective Event Manager must at least be able to confirm the output's existence and correctness, currency, etc.
When an event fails an error event may be generated, whose first purpose is to attempt to restart the failed event, including verifying and/or reinitializing any prerequisites. An alert event (auto-page) may also be generated, to notify the designated driver of a mishap. (Yuck!)
We found that we needed to track :
dependencies (conditions required prior to start, such as prior events)
normal runtime window (earliest start time, latest end time)
normal runtime length (shortest expected completion period, longest)
on-completion action (initiate subsequent event)
on-error action (re-start event, alert event, etc.)
The kinds of scheduled tasks I'm thinking about are - email reminders - garbage collection - updating syndicated content from other sites
Anybody have other examples with other use patterns?
- promoting new or updated content through develop, test, production status
- spamming users when new content gets published
- notifying content maintainers of irate feedback (after spamming users)
This sort of process may at first appear to fall outside Zope's target problem domain, but applying Zope to the task of content managment leads down this path quite directly. A Web Publishing Workflow process readily maps to an event driven system, each event triggered by the completion (or failure) of some prior event(s).
Conceptually, the leap required to see Zope in this light is to think of each request of an URL as a call to an object / method, not just a pointer to a displayable Web "page". Jon Udel's Keynote from the Zope Track points straight to this sort of Distributed Web Object model.
I have been thinking about what it would take to add "Events" to Zope, in the vein of the Property/Event/Method model of VB/Delphi/JavaBeans. The "simplest thing that could possibly work" seems to me to inject the "Obseerver" design pattern into Zope's current PropertyManager and ObjectManager classes: * PropertyManager would have installable "event handlers": - 'BeforePropertyUpdate': called just before modifying a property value, passing the object, the property name, the old value, and the new value. This handler could do anything (send mail, write to an external data store, whatever), and would return true if the change was OK (this is actually "observer-with-veto") - 'AfterPropertyUpdate': called after modifying a property value, passing the object, the property name, and the new value (this is a "pure" observer). * ObjectManager would have a set of similar handlers: - 'BeforeChildAdd' - 'BeforeChildDelete' - 'BeforeChildReplace' Something like this approach seems necessary to me to allow for generalize workflow applications in Zope. How workable does this scheme look? Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
participants (1)
-
Tres Seaver