RE: Camel 2.0 design - new schedule DSL

[Claus Ibsen <ci...@silverbullet.dk>]

Hi

Yeah quartz should definitely be used for cron and the more advanced timing features. However we should keep this DSL compatible with camel-core that just used standard java. So the quartz stuff should sort of be "pluggable".

I was also wondering if we needed somekind of callbacks features for these polling consumers so end users can do whatever business they need after the polling has finished. It could be eg. to log the job as DONE, send an email etc. There could of course be a start callback as well.

We sort of have this with the UnitOfWork but not nicely supported in the DSL.

Okay this is drifting. We should keep it about the scheduler being separated from the poller.





Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: Aaron Crickenberger [mailto:aaron.crickenberger@intalgent.com] 
Sent: 30. september 2008 20:27
To: camel-dev@activemq.apache.org
Subject: Re: Camel 2.0 design - new schedule DSL

I agree completely with the idea of breaking out polling into a more
reusable component.  The idea of having some sort of poll() or trigger()
verb in the DSL is extremely appealing.  As far as creating a seperate
scheduler, how far off is camel-quartz from providing support for this
already?

- aaron

On Sat, Sep 27, 2008 at 5:43 AM, Claus Ibsen <ci...@silverbullet.dk> wrote:

> Hi
>
> I have updated the 2.0 design wiki page.
>
> I think one of the main new features should be nice DSL support for
> schedule polls. Currently in camel the consumer endpoints might support
> ScheduledPolls but then its very basic timing (initial delay, delay,
> fixed/rate) using the simple Timer scheduler in Java.
>
> As end-users need to configure this on the endpoint directly usually in the
> from route as:
>
>   from("file://dir?consumer.delay=60000").to("bean:processFile");
>
> Since we have a mess with the options, as you need the "consumer." prefix
> thsat confuses people. I would love to get rid of it so it was just as
> before (there isn't a name clash anyway)
>
>   from("file://dir?delay=60000").to("bean:processFile");
>
> However this DSL is very basic and not all consumer endpoints support this
> scheduling - for instance iBatis, HTTP etc. It is actually not the
> responsibility of the component to handle the scheduling. The consumer
> should just run when it's invoked (receive()). However we need to support
> timeout also. receive(), receiveNoWait() receive(Timeout);
>
> So I propose to @deprecated or at least reduce the usage of
> ScheduledPollConsumer. We should let the schedule be triggered elsewhere,
> (such as the timer as now). But with build in nice DSL support.
>
>   schedule().every(5).minute().from("file://dir").to("bean:processFile")
>
> And we could consider have a poll() syntax:
>   schedule().every(5).minute().poll("file://dir").to("bean:processFile")
>
> We could consider allow ref for schedulers:
>   from(("file://dir?scheduler=pollFtpFiles").to("bean:processFile")
> to allow the old from syntax but with nice spring configuration support.
>
> <bean id="pollFtpFiles" class="org.apache...ScheduleBuilder">
>   <option name="delay" value="5"/>
>   <option name="unit" value="minute"/>
>   <option name="fixed" value="true "/>
>   <option name="initalDelay" value="10"/>
> </bean>
>
> However would be a little challenge to have nice names to allow easy
> configuration that is easy for end-users to read and understand:
>
>
> Later we can improve this builder syntax to allow cron like expression. Now
> we need Hadrians pluggable DSL ;)
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
>