Subject: Re: Can we fix BYSETPOS?

From: [email-masked]
Date: Fri, 8 Jun 2001 13:17:32 -0400

Eric replied in part with:
>  BYSETPOS MUST NOT be used with SECONDLY, MINUTELY, HOURLY or DAILY
>  rules. If any of  BYSECOND, BYMINUTE or BYHOUR rule parts appear in a
>  rule, BYSETPOS MUST NOT appear.

I mildly dislike the last line but I definitely dislike the first one.  It 
precludes simple kinds of cases where it is simpler to express a 'bigger' 
set and then pare it down using BYSETPOS.  For example, I want to 
represent "Every 20 minutes from 9:00AM to 4:40PM every day except for 12:00PM, 12:20PM (when Im eating lunch) and 4:40PM (since I 
leave at 4:30PM)" I can simply use:

RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
EXRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1

(You could 'invert' this example for my 'replacmenet' who will cover the 
instances for when Im unavailable and their example would be:
RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40;BYSETPOS=10,11,-1 )

There may be other usage models (ie: SKiCAL or some future ones) that may 
need it to have sub-day repeats and need BYSETPOS to achieve the same 
results that day (or larger) repeat intervals enjoy. 
I think we should make BYSETPOS work for all levels recurrence with the 
understanding that some cases are just insanely prohibitive to fully role 
(ie: Every second of every day year long).  If an implementation does not 
wish to support BYSETPOS on some FREQ values (or with some BYxxx 
subcomponents) then they are free to reject 'em like they would for any 
other combination of unsupported BYxxx subcomponents or combinations...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Eric Busboom <[email-masked]>
Date: Mon, 11 Jun 2001 08:32:45 -0700 (PDT)

> On Fri, 8 Jun 2001 [email-masked] wrote:

> It precludes simple kinds of cases where it is simpler to express a
> 'bigger' set and then pare it down using BYSETPOS.  For example, I
> want to represent "Every 20 minutes from 9:00AM to 4:40PM every day
> except for 12:00PM, 12:20PM (when Im eating lunch) and 4:40PM (since I

Or, you could just add another exrule:

 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
 EXRULE:FREQ=DAILY;BYHOUR=12;BYMINUTE=0,20;
 EXRULE:FREQ=DAILY;BYHOUR=16;BYMINUTE=40;

Certainly there are many rules that can be expressed with BYSETPOS -- for
any restriction you can always invent a counter example. But we only need
to implement each significant case once; we don't need to support every
fringe case in a wide variety of ways.

Can you identify some rule of general significance that absolutely
requires BYSETPOS?  If not, then we can keep the proposed BYSETPOS
restrictions without impairing the utility of the recurrence rules.

> There may be other usage models (ie: SKiCAL or some future ones) that
> may need it to have sub-day repeats and need BYSETPOS to achieve the
> same results that day (or larger) repeat intervals enjoy.

Why do we care if there are other situations where an implementation
COULD use BYSETPOS? We should only care if they MUST use it. Given the
problems we have already identified it, we should not keep unnecessary
flexibility.

> role (ie: Every second of every day year long).  If an implementation
> does not wish to support BYSETPOS on some FREQ values (or with some
> BYxxx subcomponents) then they are free to reject 'em like they would
> for any other combination of unsupported BYxxx subcomponents or
> combinations...

And that restricts interoperability. If every rule that uses BYSETPOS can
also be implemented without it, and some implementation reject some
BYSETPOS rules, then we have an unnecessary interoperability problem --
those that use BYSETPOS unnecessarily will not be understood by those that
do not accept BYSETPOS.

We already have strong evidence that this will be the case -- CPL will not
be able to accept every BYSETPOS rule under the current spec for RECUR.

It is much better that we restrict BYSETPOS now and avoid these problems.

So, Bruce, can you demonstrate that there exist common rules that cannot
be constructed with the proposed restrictions to BYSETPOS? If not, then
let's keep the restrictions.

eric.