On 30-okt-04, at 21:02, Giacomo Pati wrote:
On Sat, 30 Oct 2004, Unico Hommes wrote:
On 30-okt-04, at 18:46, Ralph Goers wrote:
Carsten Ziegeler wrote:I think the key point is that we are using Quartz as the implementation,I'm not saying don't do this, but I am asking if this is really what you want. After briefly looking at the Event interface and the Cron block, they appear to be very different. The Cron block appears to be about job scheduling, which is fine if that is really what you want. But if you really want some sort of Event handling, I'm not sure Cron is what you want - mostly I guest because I'm not sure what that means.
but not as the interface. Now we already have the quartz block with
the required implementation, so it's easy to use that.
The first step is to do this move. If then someone things that an
own implementation would be better, this can simply be changed without
destroying compatibility.
Carsten
I guess I would just like a confirmation that the interface that is going to be used is acceptable.
I agree. The focus of quartz seems very different than that provided by event and that needed by the use cases Vadim listed. Looking at the JobScheduler interface I can't shake off the feeling that cron is not the canon (honestly it's quite a beast!) best fitted to shoot the flies we are dealing with.
Vadim listed the usecase for scheduling tasks to be done once or periodically. Looking at the JobScheduler interface there just is that functionality presented. So, why do you say "The focus of quartz seems very different than that"?
All core use cases would be met by a simple timeout and delay parameter, a complete cron spec as that provided by quartz is overkill. I don't want the jobs that concurrently fetch the URLs used by the include transformer to be persisted to my RDBMS, yet that is exactly what will happen if I happen to naively use the same scheduler instance for my workflow subsystem.
We are not specifically talking about Quartz but about the JobScheduler interface. We can use the cron block as a replacement of the functionalities quickly. If you think the JobScheduler interface implementation using Quartz is not hat you need just write another one.
Looking at what is required by the JobScheduler interface, I wouldn't want to be the one assigned to that job. And I would be surprised if there was a ready to use compatible replacement for Quartz for that matter.
I think that a functionality like that provided by excalibur event is better suited for the job at hand than is quartz, and I am concerned that the Avalon debacle not only caused the concrete crisis WRT Cocoon's containment framework (which is bad), but that it has scarred us up to the point that it hurts our very nature: our cooperative spirit itself (which IHMO is much worse).
-- Unico
