[Cosmo-dev] ics UUID summary and preview proposal

[Jeffrey Harris]

Hi,

> cosmo needs to handle items with the same icaluid in the same collection
> https://bugzilla.osafoundation.org/show_bug.cgi?id=9985
> 
> Does anyone think this needs to be fixed for Preview?

I don't really think it needs to be fixed for Preview.

Changing the current behavior (if it involved rejecting anything when
doing morse code sharing) would require coordination between the Desktop
sharing team and Cosmo.

> I don't think this scenario is going to come up frequently.
> 
> As for what the solution *should* be, I feel pretty strongly that we
> shouldn't be mucking with icaluids (changing them or generating random
> ones).

I agree.

> One option is to not allow the user to put two items with the same
> icaluid in one collection -- the client should identify those as the
> same item. One could go further and say that within one client's
> repository, an imported event with the same icaluid as an existing event
> icaluid should be matched up in the repository.
> 
> Thoughts?

When Desktop imports an iCalendar file, imported events that match an
existing icalUID (or UUID) are treated as referring to the existing
item, so a single Desktop client isn't currently a vector for having
multiple items with the same icalUID.

The main way I can think of that this might happen would be if two
people independently import the same iCalendar file (this will happen
reasonably frequently if they're both invited to an event by an Outlook
or Google Calendar user, because these invitations include an iCalendar
representation of the event).

In this case, if the two Chandler users share their
differing-UUID/same-icalUID events in the same collection.  This doesn't
currently present a problem for Morse Code sharing, but it would be a
problem if someone accessed that collection with CalDAV.

Having Desktop do something different when it subscribes to a share with
an item with a duplicate icalUID would be really tricky for Preview.  It
would mean changing the UUID of one of the items, which would be a major
pain.

My preference would be to punt on this problem for Preview (allow
potential non-compliant CalDAV collection membership in this scenario).
 If we feel this is a major issue for interop, my backup preference
would be to have Cosmo hide all but the first icalUID in a given
collection when it's accessed by CalDAV, because this wouldn't impact
the Desktop.

Sincerely,
Jeffrey