[Kde-pim] iCalendar semantic

[Patrick Ohly]

On Mon, 2014-03-17 at 16:53 +0100, Kevin Krammer wrote:
> On Monday, 2014-03-17, 16:46:26, Patrick Ohly wrote:
> > On Mon, 2014-03-17 at 15:24 +0100, Kevin Krammer wrote:
> > > On Monday, 2014-03-17, 15:15:17, Christian Mollekopf wrote:
> 
> > > > Sure, if the resource can automatically fix the problem and this doesn't
> > > > lead to unexpected side effects that is a possibility. I think it should
> > > > be
> > > > avoided as far as possible because you'd want the correction to
> > > > immediately
> > > > happen. Otherwise e.g. an invalid event gets modified at some random
> > > > point
> > > > in time (when the resource tries to synchronize), instead of when the
> > > > user
> > > > modified the event, and IMO that results in a rather unexpected user
> > > > experience.
> > > 
> > > Sure. I was mainly thinking about the case when a new item is added and
> > > the
> > > resource finds a UID collision. It would then modify the UID before
> > > writing to the backend and modify the item accordingly.
> > 
> > Modifying the UID would lead to duplicates in the calendar. I don't
> > think that's the right solution.
> 
> Well, a copy operation's goal is to create a duplicate, no?

No. The goal is to import a certain event once, for example a
"calendar.ics" file containing:

BEGIN:CALENDAR
BEGIN:VEVENT
DESCRIPTION:unique event
UID:abcde
LAST-MODIFIED:20140317T170000Z
...
END:VEVENT
END:VCALENDAR

The user doesn't want to have two events called "unique event" show up
in his calendar because the UID was silently rewritten. Instead the
second import should fail or (if LAST-MODIFIED indicates a more recent
revision of the event) update the existing event.

Bye, Patrick

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/