OT: I am going to switch to some other mail client soon. It's unbelievable
that Outlook Express still doesn't do the ">" thing right :-(

>- Xron just runs on one server, e.g. the one that is on the fastest
>this is useful for cases where you need the events to be executed on the
>same machine all the time, e.g. if you want to write stuff to the server's
>local file system

"Seems like the most sensible to me.
This should be possible to do by splitting the product in two?
The Dispatcher and the Scheduler. The Scheduler gets installed on both
server and clients but the Dispatcher only gets installed on the server that
should run the triggers."

The reason why I think this behaviour should be optional is that there might
be different scenarios. There even might be a scenario where an event should
be triggered on all of the servers. But for a start I'd be happy if at least
the events are not called more than once.

"I also would like to have a Dispatch monitor ttw where the thread can be
start and stopped and the log could be read."

Would be nice indeed.

"Possibly having multiple Dispatcher (for Virtual Hosting situations), which
creates another problem because the Dispatcher is started during
product instanciation there must be a registry of Dispatchers or someway
to start the distributed Dispatcher. For example if the server is

Yep :-|

"One potential problem would also be notification of failure.
I belive I've seen a zLOG email notification product what might be useful."


>- Xron runs on all servers (i.e. ZEO clients), but on a first come first
>serve base, i.e. the server that executes the event first blocks the others
>from doing so, too.

"This would need some kind of inter-process locking, which I think should be
provided by ZEO. I'm presently not aware of any such services in ZEO?"

ZEO can't really do that at the moment. It's really just doing ZODB stuff,
which is very limited in scope. What you can do of course is just use a
global status parameter in the ZODB, but the only effect that would have is
that the first one to set that status parameter would make the other
processes fail and roll back. But a lot of stuff, like sending mails, can
hardly be rolled back ...

>Another issue is that Xron will use the current virtual host settings when
>it executes and reschedules an event. That means that the entries in the
>Xron Schedule ZCatalog will have different URLs. In some cases the URL that
>is used to execute an event could be important. E.g., we use Apache with
>some tricky rewrite rules in front of Zope, and to get around the Apache
>server the Zope server has to be called from a different URL.

"I've noticed that Xcron uses ZPublishers client to trigger events.
This seems a bit out-dated to me, wouldn't it be better to use

After looking at Xron in more detail and comparing it to the Scheduler stuff
in the Zope CVS, I guess that going the Scheduler way is probably more
promising in the long run. Xron seems to have quite a few major design
flaws. One I haven't mentioned yet is that you can only trigger DTML
methods. In a modern Zope installation, you'd probably want to call Scripts
(Python) more often, though of course you can call everything FROM DTML ...


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to