[Cosmo-dev] Recurrence modifications, filters, and diffs

[Jeffrey Harris]

Hi Brian,

> no, we're translating between icalendar and the cosmo domain model.
> 
> caldav:           icalendar <-> domain model
> morse code:   eim <-> domain model
> cosmo ui:       uses domain model directly (for the purposes of this
> discussion)

OK, that's a distinction I wasn't clear on.  Thanks.

> my point, which i didn't state clearly, was that chandler should only
> be concerned with translating its data into eim. this means that
> chandler has to unfold whatever notion of inheritance it has and turn
> that into a set of records that explicitly carry whatever data they
> are required to store into a non-inheritance-aware data store.

That's fine, as long as we're all agreed that the data store isn't doing
any munging of that data.

> and chandler shouldn't care about the mechanics of how cosmo stores the
> data, including the fact that we use icalendar and have to convert
> from an eim eventModification record that doesn't require dtstart to
> an icalendar vevent that does require dtstart. that little oddity is a
> cosmo legacy that cosmo can deal with itself without the confusing
> notion of inheritance.

Yup, agreed, this isn't particularly a Chandler issue.  I was mainly
trying to be helpful in pointing out the gotcha :)

> i don't see why chandler and cosmo ui can't realize this notion of
> inheritance using only eim's null and empty string. perhaps you've
> tried to explain this and i haven't understood it. maybe a table or
> state chart or picture or something would help.

No need for a chart, since I think it's fine to use null.  It sounds
like we're not disagreeing.  To summarize what I think the agreement is:

- EIM will use null for modification fields that are unchanged from the
master.  This is slightly confusing in the case of dtend and dtstart in
that "unchanged" doesn't mean "exactly matches the master", but we're
all consenting adults and presumably can accept that.

- EIM will use empty value (which corresponds with empty string) for the
deletion of a field in a modification, even for non-string fields.

The upshot of this is that, when Chandler processes normal records, null
and empty will be treated the same, set the field to empty.  When
Chandler processes modification records, Null and empty mean quite
different things.

Does that work for you?

Sincerely,
Jeffrey