Re: [calsify] iCalendar Series draft

[Tim Hare <[e-mail]>]

“I still feel the rules governing series should be distinct from those for recurrences”
“Simply duplicating the relevant properties with mostly the same semantics and value types”

NOT a criticism, but a question:  where and how would a series differ from recurrence?  If it doesn’t differ significantly, then the cost of implementation may exceed the benefit.

Tim Hare
Interested Bystander, Non-Inc.

 

From: calsify [mailto:[e-mail]] On Behalf Of Michael Douglass
Sent: Saturday, April 24, 2021 10:07 PM
To: Calsify <[e-mail]>
Subject: [calsify] iCalendar Series draft

 

At the last joint call there were a few questions and proposals...

*** Why standardize? ***

One was something like "why standardize this -couldn't it just be a reimplementation of recurrences".

I guess the flip reply is why standardize anything? More specifically though - how would a client store a series definition or transport it from one service to another? 

*** Why the new SRULE etc properties ***

There's still the ongoing question of whether a series is just another form of a recurrence - i.e. why do we need to replicate the recurrence properties. I still feel the rules governing series should be distinct from those for recurrences. I have had cases where a series of recurrences makes sense (university tours comes to mind) and I don't want to prevent that possibility.

To enlarge on the university tour (for prospective students). As I recall the tours were identical on each day they occurred - something like every hour. There was some sort of pattern to the actual days allocated for the tours. At the time I felt something like recurring recurrences would work.

I don't see this is a significant complication. Simply duplicating the relevant properties with mostly the same semantics and value types.

*** Template - not master ***

This is a good idea I'd like to extend. I'm inclined to see this as something distinct from series - that is a template could be used for anything.

Of course - for a template to be useful it needs some variable parts adn it may be enough to just list the properties that MUST be defined 

If we define a new TYPE and REQUIRED property we could have a template that looked like:

BEGIN:VTEMPLATE
TYPE:EVENT
REQUIRED:DTSTART,DTEND|DURATION
<a bunch of properties>
END:TEMPLATE

Of course a template could be provided completely filled in and that could take the place of the series master, e.g.

BEGIN:VTEMPLATE
TYPE:EVENT
DTSTART:20210315
DURATION:T1H
SRULE:...
<a bunch of properties>
END:TEMPLATE

I see templates being useful for events that occur irregularly but with a consistent structure - e.g. we always have a group meeting for 1 hour with a known set of attendees but there's no particular pattern to when. 

*** Self-generation ***

One part of the series draft is how many instances are generated ahead of time. This came from a discussion long ago. With many recurring events it doesn't make much sense to create an actual instance more than a few weeks in advance. Many room booking systems have a booking window of a few weeks and there's not much point in having attendees agree to attend more than a few weeks out anyway.

I think this feature is really separate from series - it could just as well be applied to recurrences.

*** Proposed changes ***

1. Come up with a separate draft defining templates. 

2. Change the series draft to use a template rather than a master. 

3. create a separate draft for the parts which define how to limit the generation of instances in advance. This would show how to apply it to recurrences and to series.