Subject: [IPTEL] Re: Current thinking on CPL/iCalendar

From: [email-masked]
Date: Tue, 20 Mar 2001 10:31:33 -0500

Patrik replied:
> Question: Is not the requirement for O(1) that the interval between
> events have to be longer than the length of the event itself?
>
> I.e. removing support for sub-24h recurrances seems too arbitrary if
> not really needed.

It may be part of the IPTEL but its not part of CALSCH's requirements.  I
dont see any rationale for this need so Im not sure _why_ it would exist.

> >Our training dept schedules multiple instances of the "same" class
> >which sometimes overlap.  I could easily be swayed by the argument
> >that there should be multiple "threads" on a per instructor basis, or
> >perhaps by room.  Just pointing out one possibility.
>
> The need for non-overlapping events is the largest requirement for
> O(1) isn't it?

Perhaps Im just not focused enough on O(1) but I do not see how restricting
to non-overlapping entries makes the performace faster.  I can understand
restricting the use or values in, say, an RRULEs due to potentially heavy
roll times.  I dont see how overlapping, explicit RDATEs violates or
prohibits O(1) so can someone please codify why?

Similar example to Daves:
A theatre lists a movie once but it may have overlapping show times.  It is
not that logical to have them PUBLISH movie times based on each individual
thatre; its more logical to just list all the showing times for a title.
A museum or company that conducts tours may have staggered schedules.
Instead of scheduling on a tour guide by tour guide basis, they are
scheduling on a tour by tour schedule.

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...
[email-masked] wrote on 03/20/2001 09:30:32 AM:

> At 08.01 -0500 01-03-20, David Madeo wrote:
> >John Stracke wrote:
> >
> >>  We talked about the CPL/iCalendar issue at the calsch dinner
> >>  tonight.  The outcome (such as it is):
> >>
> >>      + The interval between instances must be less than
> >>          24 hours.
> >
> >I'm assuming this is reversed and should be "more".  Otherwise my
> >weekly meetings are going to be a bit difficult.
> >A counter example would be the pill that I have to take every four
> >hours.
>
>
> >  >    * Possible impact on existing (or potential) applications:
> >>          o No overlapping instances--can anybody provide a
> >>            plausible scenario where you'd want them?
> >
> >Our training dept schedules multiple instances of the "same" class
> >which sometimes overlap.  I could easily be swayed by the argument
> >that there should be multiple "threads" on a per instructor basis, or
> >perhaps by room.  Just pointing out one possibility.
>
> The need for non-overlapping events is the largest requirement for
> O(1) isn't it?
>
> Because of this I think it should be stated as the main goal for
> these changes.
>
>     paf
>
>
> --
> Patrik Fältström <[email-masked]>       Internet Engineering Task Force
> Area Director, Applications Area                   http://www.ietf.org
> Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
>         PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Steve Mansour <[email-masked]>
Date: Tue, 20 Mar 2001 08:04:19 -0800

[email-masked] wrote:

> A theatre lists a movie once but it may have overlapping show times.

but they will be in different locations.

> It is

I don't know. It doesn't seems more logical to me if I was generating PUBLISH
events.  How would you list the LOCATIONs ?

> scheduling on a tour by tour schedule.

So in other words, the tour is 2 hours, there's two of them every day, they
start at 10:00 and 10:30 ?

This could be done with two separate recurring meetings as well.  May not be as
elegant, but then I can't envision the UI that would allow you to create such
meetings as a single event.

Seems like there is a reasonable workaround for the overlapping recurrences.  A
clarification stating that recurrence intervals must be greater than the
duration of the event seems like it does a lot more good than harm.

-Steve

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 20 Mar 2001 13:11:24 -0500 (EST)

> prohibits O(1) so can someone please codify why?

They don't.  The prohibition is on overlapping recurrences within an RRULE,
not on overlapping recurrences within an entire RECUR.

(For IPTel folks: this means "the prohibition is on overlapping recurrences
within a <time>, not on all the <time> nodes within a <time-switch>.)

The *total* resolution time is O(n) in the number of sub-rules of the
RECUR / outputs of the <time-switch> node, but since this is proportional to
the length of the iCalendar object / CPL, that's inevitable anyway.

-- 
Jonathan Lennox
[email-masked]

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 13:58:30 -0600

> but they will be in different locations.

...on the other hand, the users don't care about those different locations.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |That is correct. I'm out of fuel. My landing |
[email-masked]|gear is jammed. And there's an unhappy bald  |
|                |eagle loose in the cockpit.                  |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Mar 2001 14:04:51 -0600

[email-masked] wrote:

> It may be part of the IPTEL but its not part of CALSCH's requirements.

I think we have two reasons calsch needs to do something along these lines.
The first is that we would benefit no less than CPL from an O(1) evaluation of
recurring events.  Even if you expand your recurring events and put all the
instances into the database, it'd be nice to reduce the cost of that
expansion.  Also, at the moment, expanding the instances like that is pretty
much the only feasible strategy; expanding on the fly is impractical.  O(1)
evaluation would open up the field of design alternatives, which would let
people pick the right strategy for their scenario.

However, we may be able to achieve O(1) without banning the sub-day
recurrences.  If so, then we still have the issue of usability; the current
RECUR grammar is extremely complex, far too complex to express in a simple
UI.  This means that we'll get implementations that support only subsets
(there will also be those that use complex UIs, but they'll lose out to the
simple UIs over time); if we don't want to wind up with *different* subsets,
non-interoperable ones, then we'd better pick a single subset *now*.