[Zope-dev] Re. Scheduler product, anyone?

Jerry.Spicklemire@IFLYATA.COM Jerry.Spicklemire@IFLYATA.COM
Fri, 4 Feb 2000 16:50:51 -0500


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.

see	:	http://udell.roninhouse.com/ZopeKeynote.html

Later,
Jerry S.