cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <>
Subject Re: Implementation of the Continuations checker
Date Sat, 30 Oct 2004 20:44:53 GMT

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,
>>>> 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'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.
>>> 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 

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).


View raw message