On Fri, 27 Aug 1999, Phillip J. Eby wrote:
At 11:22 AM 8/27/99 -0400, Christopher Petrilli wrote:
Aside: Do you really need this within Zope if you can run a ZClient script with chron? While a scheduler within Zope isn't a bad idea, the infrastructure -- at least on Unix and NT -- is already there.
This probably shouldn't be inside Zope, as it could be pretty CPU intensive on occasion. The balance I would strike is to have an external application that uses ZClient to retrieve certain TYPES of objects and then works with them. Then you could manage it through the web, without having to have the actual threads inside Zope.
Unfortunately, unless that external application is just calling a "find the next scheduled event and execute it" method, it doesn't scale conceptually. The really interesting (to me) applications for a scheduler require more-or-less arbitrary objects to schedule future execution of their methods.
True - however doing things internally requires dealing with concurrent issues. Using ZClient or xmlrpc throws the burden on Jim ;-) The simplest idea I came up with is to have a thread internally that sleeps for a given number of seconds and then calls a simple urllib.urlopen with a URL pointing to Folderish Scheduler Product. The Scheduler product then executes registered objects (using whatever registration method) sequentially. But again .. I am not sure how security is to be dealt with. Should there be a special role, scheduler, or use proxy functionality? Pavlos