On 08/03/2015 04:30 PM, Alexander Bokovoy wrote:
On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
dragons may appear, although with a tiny tiny possibility of a golden treasure in the end.
Yes, I think intervals are required.

Alright. I gave it a little thought considering the current state of the language for time rules and considering where I should go with these intervals. The thing about the 'interval' in iCalendar is that to use it it is necessary to also add at least the 'frequency' and 'startdate' elements to the language. With that, adding 'enddate' and 'count' optional elements should not be that bad. What I am hoping for is that the same functionality as in iCalendar can be achieved here and so far I do not see why not.
So I have been struggling with this for some time but I hopefully have a solution now. As for the language, I suggest using a new keyword with possible values as in following:


Here, the date1 and optional date2 are dates in format YYYYMMDD and stand for the start and end dates. The number after + denotes the repetition interval and d/w/m/y stand for day/week/month/year periods respectively. I am omitting the SECONDLY, MINUTELY and HOURLY frequencies from iCalendar as I don't consider them appropriate for our purpose. Besides, if "repeat" is not set, the behavior is similar as with freq=SECONDLY. The number in the optional part with ':' stands for the iCalendar COUNT feature. **However**, I do not think the COUNT feature should be included in this implementation. It probably makes sense as far as the generating of "time events" (single occurences in time) goes, but in the context of time policies it seems quite confusing to me. Here are some reasons why I think it should not be included:

1. Suppose you want to set, say, something like freq=DAILY;count=100; with timeofday=0730-1600. Such range ends at 9:10 the first day and setting time with any freq+count combination would not therefore make much sense. Yes, omitting the time from COUNT would be possible solution, yet it is a different behavior as in iCalendar.

2. You want to set some really complex time policy that should repeat for certain amount of times. To me, it seems safer to set a certain fixed final date rather than have it automagically decided for you.

3. The code would get messier with COUNT included. Currently, the time policies are evaluated as they are parsed without the need of storing them. With COUNT, they will need to be stored and also, before the actual evaluation, the events would need to be generated which can be hard with more complex policies (is it possible to set an event that would never happen, yet each part describing it would be correct?).

4. Not including COUNT in implementation is not a blocker from importing from the iCalendar format. If anything, COUNT just allows generating a finite set of events. During the import, the last event of such set can be either counted and filled in as end date, or the events can just be imported one by one.

Do you consider such a solution passable?
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to