Moving my comments to this thread...
- I don't think we should be changing icaluids of events (generating
random ones), I think we need to preserve them.
- I'd vote for "A". Chandler desktop would enforce that by interpreting
imported events with the same icaluid as the same event.
Cheers,
Katie
Randy Letness wrote:
This bug describes the issue:
https://bugzilla.osafoundation.org/show_bug.cgi?id=9985
This is probably an edge case but we need to make a decision on how to
handle items in the same collection with the same icaluid. Cosmo
currently allows this, but the CalDAV spec doesn't. So do we:
A. Enforce icaluid uniqueness within collections on both the client and
server. This means any update to a collection that would result in
multiple items with the same icaluid would fail. Chandler would have to
detect this case and not allow it.
B. Allow multiple items with the same icaluid in the same collection,
but implement some workaround on the server to stay within the caldav
spec (say only expose one of multiple items with the same icaluid in the
same collection).
C. Allow it on the server and just not adhere to the caldav spec.
D. ???
-Randy
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
