Subject: [calsify] iCalendar Series draft

From: Michael Douglass <[email-masked]>
Date: Sat, 24 Apr 2021 22:07:29 -0400

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.

---

From: "Tim Hare" <[email-masked]>
Date: Mon, 26 Apr 2021 20:20:37 -0400

“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:[email-masked]] On Behalf Of Michael Douglass
Sent: Saturday, April 24, 2021 10:07 PM
To: Calsify <[email-masked]>
Subject: [calsify] iCalendar Series draft

*** 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? 

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.

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

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 ***

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.

---

From: Michael Douglass <[email-masked]>
Date: Tue, 27 Apr 2021 00:16:51 -0400

On 4/26/21 20:20, Tim Hare wrote:
> 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
>
Recurring events are treated as a single resource - that's how they are 
defined - all instances and the master have the same uid. Long running 
instances with many overrides get very large.

Rather than try to redefine how recurrences are defined and handled - 
which is going to lead to all sorts of backward compatibility issues - I 
came up with a different approach - each instance looks like a separate 
event - apart from the present of the new relation which ties it back to 
the 'master'. Older clients - in fact most clients in the future - can 
treat them as regular events.

This better matches what happens with public events for example - 
museums, art galleries etc have a series of events - lectures, public 
days etc, which occur regularly but each instance is different. Standard 
recurrences work fine until you start changing every instance.

As for the cost of implementation - it's pretty low.

> *From:*calsify [mailto:[email-masked]] *On Behalf Of 
> *Michael Douglass
> *Sent:* Saturday, April 24, 2021 10:07 PM
> *To:* Calsify <[email-masked]>
> *Subject:* [calsify] iCalendar Series draft
>
> 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
>
> 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 ***
>
> 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.
>

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 29 Apr 2021 16:26:10 +1000

> *** Why standardize? ***

It was a bit more specific than that. I was concerned that to me the current proposal:
 * Doesn't seem todo enough to be really interoperable. It doesn't define who generates the events and when. Generation is an action rather than a data, so this really needs to be a CalDAV/JMAP Calendars extension, not just a data format extension.
 * Is overly complicated in the data representation. Reproducing all the recurrence properties as SRULE etc. seemed needlessly complicated to me. And using one of the events as both an event and the template for generation seemed a mix of concerns.
I like the idea though.  I think it could work like this:
 * We define a property (e.g. `seriesId`) for events generated in a series. Clients that understand this will know that these events are related. Clients that don't can happily ignore it.
 * Series are generated on a server. We define a CalDAV extension for servers to advertise that support this.
 * To configure series generation, you store a new component type (e.g. VTEMPLATE) into a calendar. This can contain the same properties as a VEVENT, so we don't need to define many new ones: just the ones about generation. Clients that don't support the extension will just ignore these components so won't interfere, but will still allow users to read and edit the generated instances perfectly (which are just regular VEVENTs).
 * The new properties we need would be just to configure how many instances to generate in advance (either by date, e.g. two weeks in advance, or by number, e.g. max 2 events from now). If you don't add any of these properties, you still have a template that could be manually used in clients that support templates.
 * The server would generate the events by doing the normal recurrence rule expansion, but strip the recurrence properties from the VEVENT output; they would be regular standalone events, with their own UID. Other than that all properties in the VTEMPLATE would be copied over.

I think that's most of it.

Neil.