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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2001 11:11:15 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 10:32 AM
> To: Patrik Fältström
> Cc: David Madeo; John Stracke; calsch WG; [email-masked]
> Subject: Re: Current thinking on CPL/iCalendar
> 
> 
> 
> 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.

I'll let others comment on the computational implications of overlapping
events.

Another issue is problem space. For the CPL application, we are interested
in mapping people's schedules to call processing rules, i.e., "don't call me
when I'm in this meeting". For schedules for people, I don't see how there
would ever be overlapping recurring instances. Even if there were, it seems
we could handle this like we are handling COUNT, which is to expand them to
N sets of non-overlapping recurrences. 

-Jonathan R.

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

---

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

On Tuesday, March 20 2001, "Jonathan Rosenberg" wrote to "[email-masked]', Patri 	k Fältström, David Madeo, John Stracke, calsch WG, [email-masked]" saying:

> when I'm in this meeting".

While this is true, I think the rough consensus -- and the message from the
IESG -- was that, if at all possible, we should come up with a common subset
between CPL and iCalendar, so we have to consider the iCalendar's larger
problem space here.

> For schedules for people, I don't see how there

Maybe.  The unrolling algorithm isn't as straightforward as the COUNT->UNTIL
transformation, but I'll think about it.

-- 
Jonathan Lennox
[email-masked]