[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: BYSETPOS: Fresh start
Re point 1 - it is a
rare case - but in theory a BYHOUR rule could generate a variable number of
hours twice a year (i.e. the two days a year for locations with Daylight
Savings that do not have 24 hours) Even more obscurely, BYSECONDS could for the
moments of leap seconds (but this is unlikely to managed by most systems in any
case)
Also a BYMONTHDAY
or a BYYEARDAY could generate a variable number of values for a FREQ:YEAR
due to leap years (i.e. some years have more instances of MONTHDAY=29, or
YEARDAY=366. Though rules with this would be rather silly.
Also a slightly
complex case, but one that the standard is designed to allow: if you vary the
WKST setting - then rules with weekly rules or a BYWEEKNO are applied could have
variable results for a given FREQ of either MONTHLY or
YEARLY.
(to quote the
standard on what WKST does)
The WKST rule part specifies the day on which the workweek
starts.
Valid values are MO, TU, WE, TH,
FR, SA and SU. This is significant
when
a WEEKLY RRULE has an interval greater than 1, and a BYDAY
rule
part is specified. This is also
significant when in a YEARLY RRULE
when
a BYWEEKNO rule part is specified. The default value is MO.
Hope this helps
bring to light some other cases with variable result sets.
Shannon
Ok, Im totally
overwhelmed by the backlog of WG traffic that I filed away so Im going to take
a fresh start at this BYSETPOS concept again to see if I can summarize the
latest thoughts on it. Here are my takes on how things stand with
BYSETPOS based on emails and phone calls.
1: BYSETPOS is only of real use when the data set from the recurrence
rule has a variable amount of data (ie: "All the Thursdays in the Month")
For ALL other cases the recurrence rule can easily be rewritten to just
select those desired data points. So I would agree that some prose in
the updated draft could reflect this and possibly even mandate that BYSETPOS
is only used for rules that generate variable sets of data. That is to
say, in a FREQ=WEEKLY;BYDAY=MO,WE,FR rule that a BYSETPOS=2 on that should
just cause the rule to be simplified down to FREQ=WEEKLY;BYDAY=WE.
As far as we've seen
so far, the only rule that will generate a variable length data set is the
FREQ=MONTHLY;BYDAY=[MO,TU,WE,TH,FR,SA,SU] so this should not be that great an
impact going forwards. Anyone know of other cases?
2: The concern about ~31M data points is orthogonal to
the BYSETPOS issue since all the BYxxx subcomponents on a FREQ=DAILY rule w/o
a BYSETPOS can generate that large data set size. As such it is unclear
to me (at this late hour at least) why they are considered llinked.
3: iTIP / iCalendar define the use of
REQUEST-STATUS properties to back application level statuses like "Grammar too
complex", "Unsupported RRULE subcomponent", etc. Why cant this same kind
of mechanism be reused in CPL when a rule uses a BYSETPOS or generates a data
set too large for O(1) evaluation?
4: Much of the bitter back and forth seems to focus on very extreme
cases (ie: "bombing" CS/CPL servers) rather than on the 'normal' usages that
the vast majority of installations will deal with on a regular basis.
Sure we have to deal with some DOS or other maliscious kinds of activity
at various levels of design bug I suspect that these fringe cases have
distracted us from the real technical work.
So how about we refocus on the items above or if
I left any off that we put them on the plate anew and try to get on the same
page. I talked w/Tom (Robert) today before dinner and he seemed to think that
we were all in basic agreement about how recurrence grammars get expanded.
If this is not quite accurate then Im willing to try and restart that
again too.
Time to get some
sleep...
Bruce
===========================================================================
Bruce
Kahn
INet: Bruce_Kahn@xxxxxxxx
Iris
Associates
Phone: 978.392.5335
Westford, MA, USA 01886
FAX: and
nothing but the FAX...
Standard disclaimers apply, even where prohibited by
law...