Hi Randy and Morgen, >>> - Putting a DTSTART and a DTEND into icalendar even if they weren't >>> changed >>> - NOT putting DTSTART and DTEND into EIM unless start time or duration >>> was changed by the modification >>> >> We could do this. Cosmo would just have to do some extra calculations >> using the recurrence id and master event's start/end time (duration). >> So if an event is created via CalDAV that includes start/end times for >> all modifications does this mean you want Cosmo to strip the >> unnecessary start/end times when Chandler syncs (only send start/end >> if they weren't changed)?
Yes, exactly. > There are currently three null-ish values in the EIM world: > > - None/Null (the field has no value at all) -- [I'm using "None/Null" > because in Chandler we use the python symbol None, and the EIMML spec > refers to Null] > This is serialized in EIMML as <element /> > > - Empty (the field has a value, and it's "empty", as in an empty string > or an empty list) > This is serialized in EIMML as <element empty="true" /> > > - NoChange (used only internally within diff records -- the field hasn't > changed) > This is not serialized in EIMML at all. The *absence* of an element > is an indicator of NoChange > > Say we have a master event with a reminderTime; now Chandler wants to > create a modification event that doesn't have a reminderTime. Does > Chandler emit a "None/Null" for that field, or an "Empty"? If Chandler > emits "None/Null", then there isn't a way to later indicate the > modification should inherit the value from the master. However, if > Chandler emits "Empty" to represent the modification doesn't have a > reminder, then later on Chandler can emit "None/Null" for that field to > indicate the modification should now inherit from the master. Jeffrey, > does that solve the problem? I think that should work fine, as long as we're all on the same page about what our various nulls mean. So, to summarize, Chandler will emit Empty for the specific removal of a field, and None/Null for fields that inherit from the master (including startTime/endTime, with our common understanding of the meaning of inheriting these values). I'll note that this means there's no syntactic way to distinguish between an empty string in a modification field and the removal of the entire field. There's no practical difficulty with that right now, and I think it'd be a bad idea for anyone to write Chandler code that made a serious distinction between an empty string value and the absence of the value, so I'm not especially concerned with this. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
