[Chandler-dev] Re: [Cosmo-dev] Recurrence modifications, filters, and diffs

Jeffrey Harris jeffrey at osafoundation.org
Fri Feb 9 12:42:40 PST 2007

Hi Brian,

> this seems totally backwards.
> cosmo's domain model doesn't care about inheritance. it just cares
> about what properties an item has and what properties a modification
> has.

Either I don't understand what you're saying, or I disagree with you.

Cosmo, the server, DOES care about the mechanics of modifications
because you're translating between EIM and iCalendar in the CalDAV layer.

> eim requires a dtstart and a dtend for a master event and for an
> exception event.

Was this a typo, did you mean icalendar, not eim?  If you meant eim, I
disagree, EIM needn't require a dtstart or a dtend in a modification.
But icalendar does require them.  I don't believe EIM's requirements
should be beholden to icalendar's requirements.

> chandler and cosmo ui should be responsible for
> setting those fields in those records appropriately. chandler and
> cosmo ui are the things that care about inheritance, so the burden
> should be on them to do whatever needs to happen to get a dtstart and
> a dtend into an exception event record.

I agree, as long as everything's working with EIM.  But if Cosmo gets an
icalendar version of a recurring event via CalDAV, the translation needs
to happen.  And at the moment, Cosmo UI doesn't look at EIM records, it
looks at the icalendar Cosmo translates EIM into.

> in eim, a null field value means that value is meant to be deleted. in
> eim, an empty string text value means just that - the corresponding
> item or modification attribute is meant to have "" as its string
> value.
> let's not get eim and cosmo's storage mixed up with application features.

Randy suggested it might be simpler to reuse Null for what I consider a
distinct semantic meaning: inherit this field, don't delete it, don't
set it to empty.  I'm amenable to that simplification, but what I'm
taking from your response is that you'd prefer the syntax be different
for different semantics.  Of course I'm amenable to that, too.

Or are you're arguing Chandler/Cosmo don't need to agree on a syntax for


More information about the chandler-dev mailing list