[rules-dev] Fwd: Duration suggesstions

[Geoffrey De Smet]

I can recommend the newsgroup nntp://news.gmane.org to browse and post 
to the list, without it flooding your inbox :)

With kind regards,
Geoffrey De Smet


Mark Proctor wrote:
> Tony,
> 
> The list is self service, and each post contains a url to the web page 
> to unsubcribe yourself:
> https://lists.jboss.org/mailman/listinfo/rules-dev
> 
> Mark
> Tony Ross wrote:
>> please please unsubscribe me from this 
>>
>>
>> On 28 Dec 2007, at 14:31, Mark Proctor wrote:
>>
>>> -------- Original Message --------
>>>
>>> Dear Mark,
>>>
>>> Thanks again for your tasty BOF at Javapolis07, it was a pleasure 
>>> meeting you.
>>>
>>> As you suggested me to post it, here is the feature request we talked 
>>> about:
>>>
>>> Our company often has to code time spans across working hours for 
>>> ticketing systems (issue tracking/service calls) in accordance with 
>>> ever-changing SLA (service level agreements). Those times calculi are 
>>> PAINFUL in an imperative language.
>>>
>>> Therefore I wish I could have a modification of the 'duration' 
>>> principle that would allow the coding of such rules:
>>>
>>> When
>>> a customer ticket is opened for more than two hours during 
>>> working_hours_2008
>>> and state is urgent
>>> then
>>> send a reminder to the support team and the team leader
>>> -
>>> When
>>> a customer ticket is opened for more than four hours during 
>>> working_hours_2008
>>> and state is urgent
>>> and no action taken
>>> then
>>> escalate ticket
>>>
>>> This might require:
>>> * A scheduling mechanism such as quartz (sort of java combination of 
>>> 'at' and 'cron' Unix commands with extension capabilities) to trigger 
>>> the second assertion of the LHS at a specific time.
>>> * New syntax tokens: during, "for"
>>> * New nonterminal symbols after these tokens (composite date and time 
>>> classes)
>>>
>>> I have since then had a talk with Stephen Colebourne at Javapolis; he 
>>> is the responsible of the JSR 310 Date and Time API 
>>> (http://jsr-310.dev.java.net).
>>>
>>> I have proposed him to extend the scope of the JSR to accept 
>>> composites of DatesWithoutTime and TimeIntervals objects to enable 
>>> the retrieval of a OffsetDateTime by calculating the span of a 
>>> Duration trough a CompositeDateAndTimeInterval.
>>>
>>> An example is much more clear:
>>> CompositeTimeInterval working_hours = EnhancedTimeInterval(Mon tru 
>>> fri 8:00 to 20:00)
>>> TimeInterval lunchbreak = 12:00 to 12:45
>>> CompositeDateWithoutTime belgiumBankHolidays2008 = 1 Jan 2008, 23 Mar 
>>> 2008, 24 Mar 2008, 1 May 2008, 11 May 2008, 12 May 2008, 21 Jul 2008, 
>>> 15 Aug 2008, 1 Nov 2008, 11 Nov 2008, 25 Dec 2008
>>> CompositeDateWithoutTime specialOpeningDays = Sun 20 Feb (launch of 
>>> our new super awaited product), Sun 21 Dec (shopping day before Xmas)
>>> CompositeTimeInterval working_hours_2008 = new CompositeTimeInterval()
>>> working_hours_2008.include(working_hours)
>>> working_hours_2008.exclude(lunchbreak)
>>> working_hours_2008.exclude(belgiumBankHolidays2008)
>>> working_hours_2008.include(specialOpeningDays)
>>>
>>> This composite is to be used after the 'during' token. The duration 
>>> would require its own syntax token (the word 'for' is already 
>>> overused in programming languages, it could lead to confusion)
>>>
>>> These composites would have to be defined somewhere at sometime for 
>>> the BRE to access them. Could they be directly defined in rule 
>>> packages? Or accessed as
>>>
>>> Thus, in order:
>>> * assert LHS's CEs
>>> * calculate the time span of the duration across the 'agenda' (also a 
>>> confusing keyword, would it be good English to call it schedule?)
>>> * set an event in the future for the matched object
>>> * when it’s event time: callback the object LHS assertion
>>> * and if still true, execute RHS
>>>
>>> I would be very happy to contribute to the implementation of this 
>>> feature, please let me know if you (and your team) are interested in 
>>> such a feature.
>>>
>>> Looking forward to hearing from you,
>>>
>>> Stanislas Herman Rusinsky.
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>> Tony Ross
>>> Portal Consultant
>>>
>>> UPC Broadband Holding Services
>>> CIO Web Delivery
>>> Boeing Avenue 53
>>> 1119 PE Schiphol-Rijk
>>> The Netherlands
>>>
>>> M:+31 (0)6 347 125 11
>>> E: tony.ross at mac.com <mailto:tony.ross at mac.com>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>   
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev