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

[Jeffrey Harris]

Hi Morgen,


> One way would be to add a (persistent) dictionary attribute to Chandler
> Event items which hold all non-standard icalendar properties. 
> (Non-Chandler devs, excuse my python):
> 
>     class EventStamp(Stamp):
>         icalext = schema.Mapping(schema.Text)
> 
>     event.icalext = { 'X-APPLE-FOO' : 'xyzzy', 'X-APPLE-BAR' : 'plugh' }

Generally speaking, this is where I hope we head with icalendar data.

Unfortunately, it's a little more complicated than this, because not
only values can be custom on icalendar data, but also parameters.

So we might have:

1) X-RANDOM-FOO;X-RANDOM-PARAM-X="Glorious marvelous mud!":xyzzy

Even more tricky, we might have:

2) DTSTART;X-RANDOM-PARAM-CHANGING-SEMANTICS="Gotcha":20061213

This is a property that Chandler *does* understand, with a parameter we
don't.

This suggests having two dictionaries, one giving values, the other
giving parameters.  When serializing, we'd add back entire properties we
didn't understand along with their parameters, and also iterate over
known custom parameters when serializing things we did understand.

I think we might want to throw away parameters on an attribute we
understand if we change that attribute.  For example, Chandler currently
serializes anytime events as iCalendar all-day events, plus a custom
parameter:

DTSTART;VALUE=DATE;X-OSAF-ANYTIME="True":20061213

If another application changed that start time to be, say, a timed event
from 2-3pm, it'd be nice if the application on the other end threw away
our X-OSAF-ANYTIME.

For now, I'm going to make Chandler just naively keep parameters,
because it's less work, and I suspect it may be good enough in most
situations.

There's an obscure wrinkle in all this if a custom component has a
timezoned date-time, in that instead of interpreting the property as a
date time, we treat it as a string with a TZID=Whatever/Timezone
parameter.  This will be fine if we serialize a VTIMEZONE that matches
that TZID, but under many circumstances we won't create a matching
VTIMEZONE.  I think that's OK, basically, people creating custom
properties shouldn't count on anything but text being preserved, but I
thought I'd mention that I worried about it for 10 minutes before
dismissing the problem :)

> Yeah, reminders are something we haven't yet added to the EIM record
> types yet.  What information do you need to transport?  Can it simply be
> represented by one or two fields as part of the EventRecord ?  By the
> way, the record types we have defined are at http://tinyurl.com/w4s9f .

Chandler's current data model treats reminders as being either a delta
from an existing event's start time (deltas are preferred to make sense
of reminders on recurring events), or as a definite time (i.e. 5PM Dec.
13, 2006) reminder on any item.  For now that's all there is to it from
Chandler's perspective.

There's lots more semantic information for VALARMs that iCalendar
defines, you can have more than one, they can have a description, and
they can specify an action when they go off (display, play a sound, send
an email, etc.).  Chandler ignores all that for now.

As long as Cosmo won't throw up its hands in disgust if it needs to
serialize two related items as one when it's turning an item into an
iCalendar event (BCM's response made me think this is reasonable to hope
for), serializing reminders to iCalendar should work fine when we get
around to it.

Sincerely,
Jeffrey