[Cosmo-dev] Cosmo 0.6 sharing

[Randy Letness]

Brian Moseley wrote:
>
> the complicating factor i think is that for caldav we don't actually
> convert the icalendar data into a stored representation and then
> convert the stored thing back to icalendar. we actually store the
> icalendar data itself and then send that exact same sequence of bytes
> back. so an event created with caldav but shared with morse code needs
> to get converted from icalendar (an ical4j object) to eimml rather
> than from a CalendarEventItem.

One of the nice things about storing the icalendar blob is that
there is no data loss (X* components,attributes, etc).  There
isn't a way to express this extra data in EIM (without storing
the icalendar blob), so what happens  when Chandler pulls
an event that was created with a CalDAV client and contains
extra data that can't be expressed in EIM, and then updates it? 
Would the data be lost?  We could keep the original icalendar
blob around, but then there is the problem of merging, which
would start to get complicated.
>> The example I was thinking about was an item with association
>> records.  Each association (tag for instance) is represented as
>> a record, so an item can have any number of association
>> records, all with the same namespace, just different values.
>
> hm, then maybe we don't model those assocations as attributes?

The problem is that for generic EIM, you don't know which
records are associations records.  They are just EIM records
until you know something about the record type, more than
just the type of fields too.  You really have to know ahead
of time that this record type is an association record.  I guess
you could assume that if you have multiple records with the
same namespace, you have association records, but that fails
when you only have one.


-Randy