Hi! 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 machine; >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 restarted." Yep :-| "One potential problem would also be notification of failure. I belive I've seen a zLOG email notification product what might be useful." Yes. >- 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 restrictedTraverse?" 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 ... Joachim _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )