Re: [calsify] iCalendar Series draft

[Michael Douglass <[e-mail]>]

On 4/26/21 20:20, Tim Hare wrote:
>
> “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
>
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.

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