[Cosmo-dev] custom iCalendar data in an EIM world

[Brian Moseley]

On 12/14/06, Morgen Sagen <morgen at osafoundation.org> wrote:

>         class IcalExtensionRecord(sharing.Record):
>                 URI = "http://osafoundation.org/eimml/icalext"
>
>                 uuid = sharing.key(ItemRecord.uuid)
>                 name = sharing.key(sharing.TextType(size=256))
>                 value = sharing.field(sharing.TextType(size=1024))

i've discovered a couple of issues with this approach with respect to
multiple instances of an icalendar property. take for example the
COMMENT property, which can occur in a VEVENT more than once:

COMMENT:this meeting will be too long. --bcm
COMMENT:I will be in Palo Alto for this meeting. --Morgen
COMMENT:I will chair this meeting. --Jeffrey

(bear with me. this is a totally contrived example, but it gets the
point across.)

chandler can either serialize multiple property instances into one
record (which runs the risk of busting the value max length) or send
one record for each property instance. let's assume we do that to
ensure no data loss.

let's say the value changes for one of the comments:

COMMENT:I will be in SF for this meeting. --Morgen

the eim primary key (record type, item uuid, property name) does not
have enough information to identify which property instance changed.

chandler could theoretically send the old value along with the updated
value, which would allow cosmo to find the correct instance. or
chandler could send a deletion record for the instance and another
record treating the updated comment as a new property instance.

also, what happens if one of the comments is deleted? even if chandler
is able to remember the deleted status for an individual property
instance, cosmo can't. so if somebody uses a third party app to delete
one of the comments from the cosmo event, cosmo does not have the
ability to remember that the next time it has to convert the event to
eim records.

could we make a rule that chandler and cosmo always send a record for
every icalendar property instance that doesn't map to a field defined
in the event record type? that way when it applies an update from
chandler, cosmo could simply remove all non-eim-event icalendar
properties from the event and then add properties for each icalext
record sent from chandler. this means of course that there would never
be a need to send delete records for icalendar properties.

since there are typically going to be few if any of these properties
for any given event, this shouldn't considerably add to overall
publish/update time, especially since cosmo stores all icalendar
properties in a single icalendar blob in its database.