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