[Cosmo-dev] Item.uid and icalendar UID

[Brian Moseley]

On 10/16/06, Jared Rhine <jared at wordzoo.com> wrote:
> On Mon, 2006-10-16 at 17:31 -0500, Randy Letness wrote:
> > So the question is: should Cosmo allow multiple calendars to contain
> > events with the same icalendar UID, making sure the UID is unique
> > within the same calendar collection?
>
> Absolutely, in my mind.  Anything else would make at least testing a
> serious pain in the butt.  For users, people wouldn't be able to create
> an account, forget their info, and create another one as they tend to
> do.  They'd be stuck and not able to re-import their calendars.
>
> Most data-storage services with accounts (email, etc), really work
> better when accounts are almost totally separate and have minimal
> ability to impact each other.

the central question is: what defines the identity of an item? is it
the cosmo uid, the calendar uid, or both?

we talked about this a while back, and the conclusion was both, and
that we should unify the cosmo and calendar uid. now it's certainly
possible that we didn't think the problem through well enough. randy,
i don't recall you participating in that thread ;)

if we make the cosmo and calendar uids be the same, the implication is
that once somebody puts a calendar item with a certain calendar uid
into the server, then any time in the future another calendar item
with the same calendar uid is put into the server, it's assumed to be
an update to the origina item.

jared's use case suggests that we need to actually create multiple
items on the server (with different cosmo uids) from the same
"client-side" calendar object, which means that each cosmo item would
have the same calendar uid. thus, calendar uid couldn't participate in
item identity and would simply be just another calendar property to
which cosmo doesn't assign any particular meaning.

i think jared's right, and i'm fine with backing off on unifying the
cosmo and calendar uids.

i also want to point out that no matter how we decide this issue,
certain things will be true in the future:

* item uids will need to be settable by chandler during synchronization
* items will need to be able to live in multiple collections without
having multiple "item copies" in the database ("item soup")

we don't need to worry about either of these requirements now, but at
least the first one will be coming up in 0.6.