In article <news2mail-87e7ql$m7k$1@mate.bln.innominate.de>, Thilo Mezger <news-list.zope.dev@innominate.de> writes

"Loren Stafford" <lstaffor@dynalogic.com> wrote:

...

At one time there was talk on this list (or zope@zope.org) of building a scheduler product -- something that would automatically execute specified methods at specified times or time intervals.

...

Does anyone have such a product in the works? ...or is it time for me to roll up my sleeves and get to work?

would that be a lot different from writing an external python script that would be run by cron (on unix) and trigger a zope method via xml-rpc...?!

thilo

Is there any nice way to get xmlrpc to pass a login/password to a server that requires it? I looked in vain for such a thing in xmlrpclib.py. Are all xmlrpc servers assumed to be world executable? I looked in xmlrpclib.py ad it doesn't seem to use splituser so presumably can't get at user:password. -- Robin Becker

In article <NCBBJLKNGPHKAPILLHDKOEPGCMAA.jens@digicool.com>, Jens Vagelpohl <jens@digicool.com> writes

hi robin,

it is true, the current version of xmlrpclib doesn't do authentication.

amos latteier wrote a howto on using zope as an xml-rpc server and he was put up a patch for xmlrpclib that will let you use authentication:

http://www.zope.org/Members/Amos/XML-RPC

that should at least point you in the right direction.

jens

... thanks -- Robin Becker

On Fri, 4 Feb 2000, Loren Stafford wrote:

What I have in mind is a product that includes a schedule data structure containing tuples of (date/time, method to call), a Dispatcher method, and a Scheduler method:

1. Cron runs a Dispatcher method via RPC.

2. Dispatcher looks in schedule table, finds next scheduled method in table, and runs it as a separate transaction (could use RPC), and removes the entry from the table.

It may be possible to do this from within Zope and not involve cron at all. Your Scheduler product could fire off a seperate thread when its package is first loaded. Has the advantages of only attempting calls when Zope is running, and being platform independant.

3. Schedule-aware objects can use the Scheduler method to schedule one of their methods for execution at a given time. The schedule-aware object would specify the URL of scheduled method. Simple RPC would be the default. XML-RPC would be possible (but as I have no need for it I probably would leave a hook to extend the product). Repetitive tasks can reschedule themselves each time they are called.

Why the requirement for being schedule-aware? I personally would want an interface that could be used from arbitrary DTML, external methods or python methods using aquisition: <dtml-comment>Assumes an object with Id 'Schedule'</dtml-comment> <dtml-call "Schedule(myMethod.absolute_url(),ZopeTime() + 60)"> If an Id is returned from the Schedule(...) call, it would be possible to unschedule as well. -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen

On Mon, 7 Feb 2000, Loren Stafford wrote:

...

It may be possible to do this from within Zope and not involve cron at all. Your Scheduler product could fire off a seperate thread when its package is first loaded. Has the advantages of only attempting calls when Zope is running, and being platform independant.

Great idea! However I can't quite get my mind around the implementation in Zope:

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.

In here, or in a module that is imported from __init__.py.

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.

The module will only ever be instantiated once - this is how package global variables are done. All you are doing is creating a package global (which is actually a running thread object).

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?

The process which needs to find the scheduled events (either a thread or from cron) needs to look for them in a known location. The easiest implementation of this would be to have a single object called 'Schedule' stored in the root of the Zope tree. Now - if you make this Schedule object a subclass of ZCatalog, then it will be trivial for an 'Event' object to tell the Schedule object that it exists - just make the Event object a subclass of CatalogAware, and make its default catalog name 'Schedule' instead of 'Catalog' and all the work is done for you. In this scheme, you end up with one central queue, but can scatter Event objects wherever you feel like it. This simplifies the logic, as an Event object only needs to be able to handle one event rather than maintaining a list. If this Event object could be subclassed in Python products or ZClasses, it would be possible to create custom applications that are Schedule aware.

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?

If you are accessing the ZODB like an external client would (HTTP, XML-RPC, whatever) then there is no problem. It would be possible to access the ZODB directly like any other Zope thread, but then you would have to use the same transaction mechanics (this might be simple - you would have to go through the UML ZODB definition in the Resources section of zope.org or ask a Digicool employee nicely :-) ) -- ___ // Zen (alias Stuart Bishop) Work: zen@cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen@shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen