Re: [calsify] Warren Kumari's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT)

[Barry Leiba <[e-mail]>]

Indeed, and I would have found this sort of thing to be useful in many
cases.  Of particular importance is being able to change the
subject/summary for myself, or to add a relevant URI, while still
being able to get event updates such as time/date changes, agendas
added to the description, and such.  At IBM I would frequently get on
some VP's calendar with a meeting invitation that said "Meet with
Barry", which wasn't very useful for me.  But if I made my own copy
that said "Meet with Jane the VP", when it inevitably got rescheduled
because something more important came up for Jane, it would all be a
mess.

In any case, Neil, I think Warren is less interested in your
explaining it to *him* and more interested in seeing some sort of
explanation in the document.  I agree that it would be useful to have
something in the document.

Barry

On Tue, Sep 29, 2020 at 11:46 PM Neil Jenkins <[e-mail]> wrote:
>
> Hi Warren,
>
> I think that it would be useful to have some more discussions around why / when
> PatchObjects should be used - they seem to add significant complexity to the
> design, and I'm really not convinced that the complexity outweighs the benefit;
> I'm guessing that I'm simply not fully understanding their utility.
>
>
> There are two primary benefits:
>
> Significantly reducing file size and duplicated content. For example, if one person is not going to a particular instance of a regularly scheduled event, in iCalendar you would have to duplicate the entire event in the override. In JSCalendar this is a small patch to show the difference.
> Better preservation of semantic intent: if a user changes the time of a single occurrence in an event series, only this property is overridden so if you change (for example) the location of the master event, the occurrence will automatically still inherit this.
>
> Cheers,
> Neil.