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 ``` 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... I want to sleep one more night on it. What do you think? Cheers, -- John Mettraux - http://lambda.io/jmettraux -- -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] more options : http://groups.google.com/group/openwferu-users?hl=en --- You received this message because you are subscribed to the Google Groups "ruote" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
