Re: [Evolution-hackers] Evolution calendar backend

[Adam Tauno Williams <awilliam opengroupware us>]

On Sat, 2011-01-22 at 14:18 -0500, Adam Tauno Williams wrote: 
> On Sat, 2011-01-22 at 10:57 -0600, Kirk Wolff wrote: 
> > Hello,
> > I've been digging through calendar's webdav backend 
> The calendar is CalDAV [it uses REPORT methods]; a descendant of WebDAV.
> > code and found that 
> > there's special handling of calendar items (components) that have
> > the same UID.  Under what circumstances would two calendar items
> > have both the same UID and href?  
> I suppose this could happen in the case of editing a recurrence [I don't
> specifically know how evolution internally handles recurrences;  but I
> work on a CalDAV server and ... man, are recurring events in iCal/CalDAV
> stupid and a pain].

RFC4791

4.1.  Calendar Object Resources

   Calendar object resources contained in calendar collections MUST NOT
   contain more than one type of calendar component (e.g., VEVENT,
   VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
   components, which MUST be specified for each unique TZID parameter
   value specified in the iCalendar object.  For instance, a calendar
   object resource can contain one VEVENT component and one VTIMEZONE
   component, but it cannot contain one VEVENT component and one VTODO
   component.  Instead, the VEVENT and VTODO components would have to be
   stored in separate calendar object resources in the same collection.

   Calendar object resources contained in calendar collections MUST NOT
   specify the iCalendar METHOD property.

   The UID property value of the calendar components contained in a
   calendar object resource MUST be unique in the scope of the calendar
   collection in which they are stored.

   Calendar components in a calendar collection that have different UID
   property values MUST be stored in separate calendar object resources.

   Calendar components with the same UID property value, in a given
   calendar collection, MUST be contained in the same calendar object
   resource.  This ensures that all components in a recurrence "set" are
   contained in the same calendar object resource.  It is possible for a
   calendar object resource to just contain components that represent
   "overridden" instances (ones that modify the behavior of a regular
   instance, and thus include a RECURRENCE-ID property) without also
   including the "master" recurring component (the one that defines the
   recurrence "set" and does not contain any RECURRENCE-ID property).

   For example, given the following iCalendar object:

   BEGIN:VCALENDAR
   PRODID:-//Example Corp.//CalDAV Client//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:1 example com
   SUMMARY:One-off Meeting
   DTSTAMP:20041210T183904Z
   DTSTART:20041207T120000Z
   DTEND:20041207T130000Z
   END:VEVENT
   BEGIN:VEVENT
   UID:2 example com
   SUMMARY:Weekly Meeting
   DTSTAMP:20041210T183838Z
   DTSTART:20041206T120000Z
   DTEND:20041206T130000Z
   RRULE:FREQ=WEEKLY
   END:VEVENT
   BEGIN:VEVENT
   UID:2 example com
   SUMMARY:Weekly Meeting
   RECURRENCE-ID:20041213T120000Z
   DTSTAMP:20041210T183838Z
   DTSTART:20041213T130000Z
   DTEND:20041213T140000Z
   END:VEVENT
   END:VCALENDAR

   The VEVENT component with the UID value "1 example com" would be
   stored in its own calendar object resource.  The two VEVENT
   components with the UID value "2 example com", which represent a
   recurring event where one recurrence instance has been overridden,
   would be stored in the same calendar object resource.