Thank you for your reply.
On 13-06-23 03:35 AM, John Mettraux wrote:
> On Sat, Jun 22, 2013 at 05:17:17PM -0400, Jean-François Rioux wrote:
>> I have use cases that express the need for timers that would escalate as
>> the deadline approaches. Something in the lines of:
>>
>> Item is due in 24 hours.
>> For the first 12 hours, notify every 4 hours
>> For the next 6 hours, notify every 2 hours
>> For the next 4 hours, notify every hour
>> For the last 2 hours, notify every ½ hour
> With a ruote timer, that'd look like:
>
> ```ruby
> admin :timers =>
> '4h: notice, 8h: notice, 12h: notice, 14h: important, 16h: important, ' +
> '18h: important, 19h: urgent, 20h: urgent, 21h: urgent, 22h: urgent, ' +
> '22h30m: escalation, 23h: escalation, 23h30m: escalation, ' +
> '24h: escalation'
> ```
>
> Yes, it's "long en bouche" (heavy on the palate maybe?).
>
> The timers can be placed in a process variable though.
>
> ```ruby
> set 'v:reminders' =>
> '4h: notice, 8h: notice, 12h: notice, 14h: important, 16h: important, ' +
> '18h: important, 19h: urgent, 20h: urgent, 21h: urgent, 22h: urgent, ' +
> '22h30m: escalation, 23h: escalation, 23h30m: escalation, ' +
> '24h: escalation'
> # ...
> admin :timers => '${v:reminders}'
> ```
>
> This is also possible:
>
> ```ruby
> sequence do
> sequence :flank => true do
> every '4h', :timeout => '12h' { remind_notice }
> every '2h', :timeout => '6h' { remind_important }
> every '1h', :timeout => '4h' { remind_urgent }
> every '30m', :timeout => '2h' { remind_escalation }
> end
> admin
> end
> ```
I'm sorry, I did not stress one important point of our case.What's very different from your approach is that we have an accorded delay which defines a certain `limit` in time. From that `limit`, we need to go backward to define notification schedules, e.g., one day before this limit, send me an email each hours and copy my boss. It's important to understand that this `limit` is calculated by the `start time` + the `delay` and the former is not always time.now. This means, the timers will not always be triggered statically in time (e.g., in your example, the first timer will always be 4h after the process has being started). >> I wanted a syntax in the form of: >> >> action:[start, end]/frequency; action2:[start, end]/frequency; ... >> actionN:[start, end]/frequency; >> >> Where <action> is the participant being called, <start> is the first >> moment the participant is called, <end> is the last moment the >> participant is called, and frequency being the lap time between each >> notification within the range of <start> and <end>. >> >> So, in the case of the example above: >> >> [...] >> Ruote.define 'our_timers_test' do >> sequence do >> admin_participant :delay => delay, :our_timers => 'notice:[-24h, >> -12h]/4h; important:[-12h, -6h]/2h; urgent[-6h, -2h]/1h; >> escalation:[-2h, 0]/30m;' >> end >> end >> [...] >> >> I've took a look at :timers and the `cron`expression and realized our >> requirements were somewhere in the middle: >> - :timers are an attribute we pass to a participant/subprocess but it >> can only write schedule documents up front; and > What do you mean by "write schedule documents up front"? I'm referring to Ruote::Exp::FlowExpression::schedule_timers, which writes an `at` document for every timer. >> - `cron` expressions are re-evaluated each time they get executed >> `CronExpression::reply -> CronExpression::reschedule` but they are an >> expression, not an attribution. > I think the "every" as seen above might be better suited. Its timeout needs > maybe some kind of margin... (for example, the 12h timeout firing right on > the last notification of the first 12 hours). > >> Basically, I'm levering the existing mechanism for timers and I added an >> alias around (Ruote::Exp::FlowExpression::consider_timers) . >> >> I've included my current implementation and my current specs in this gist : >> https://gist.github.com/jfrioux/d1b945e12edb772f61ed#file-timers_spec-rb-L5 >> >> My current set of basic specs is passing fine, but I wanted to know, >> since I'm rather a beginner with ruote, if anything in my implementation >> seems off or problematic to you, based on your own mileage. >> >> John, is this something that could be merged to Ruote itself or should >> it be provided as a gem? > I think it makes sense, but I'd prefer and language like > > ```ruby > admin :timers => > '0h-12h/4h: notice, 12h-18h/2h: important, 18h-22h/1h: urgent, ' + > '22h-24h/30m: escalation' > ``` Ok I see. I guess what's problematic is the minus in our case. We would end up like: '-24h--12h/4h: notice, -12h--6h/2h: important, -6h--2h/1h: urgent, -2h-0/30m: escalation' ...which doesn't seems right. > It'd follow the current "{time stuff}: {participant|subprocess|action}". > > > What do you think? > > -- > John Mettraux - http://lambda.io/jmettraux > Thanks -- Jean-Francois Rioux Co-founder Mantor Organization
signature.asc
Description: OpenPGP digital signature
