On 13-06-24 02:50 PM, John Mettraux wrote: > On Mon, Jun 24, 2013 at 01:28:12PM -0400, Jean-François Rioux wrote: >> (...) >> >> 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). > Hello, > > oops sorry, I indeed misread you. > > I thought :delay was some kind of "delay" before the workitem became > available to the participant. > > >>>> (...) >>>> >>>> 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. > OK. > > >>>> - `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. > Somehow, you want to replace "timeout" with "delay" and then express the > timers relatively to the delay/timeout. > > ```ruby > # Jean-François: > admin :delay => "10d", :timers => "-24h: notice, -12h: urgent" > ``` > > ```ruby > # John: > admin :timers => '9d: notice, 9d12h: urgent, 10d: timeout' > ``` > > I'm not convinced by "delay", I really understand it as "put off until a > later time". (Granted, I'm not a native english speaker). In french, we say > "dans les delais" to mean "within the imparted time", but well... > > When I see this: > > ```ruby > admin :delay => "10d" > ``` > > I think: > > ```ruby > sequence do > wait '10d' > admin > end > ``` You are right. Futhermore, if we are having this conversation, delay is without a doubt a poor name for it (Entièrement d'accord avec vous ). I'll try to come up with something more suiting. > > Back to the timers, could we go with something like: > > ```ruby > admin :timers => "-1d: notice, -12h: urgent, 10d: timeout" > ``` > > (the last one is the reference). > > But then we still have to be able to express your ranges and frequencies... > Yes. Personally, I thought the the "mathematical interval notation" rather suiting for that task:
'[a, b]/y: notice' The only downside I could think of is that is resembles Ruby's Array notation,... > I want to sleep one more night on it. What do you think > > > Cheers, > > -- > John Mettraux - http://lambda.io/jmettraux > Thank you, -- Jean-Francois Rioux Co-founder Mantor Organization
signature.asc
Description: OpenPGP digital signature
