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

Morgen Sagen morgen at osafoundation.org
Fri Feb 9 09:03:20 PST 2007

cc'ing chandler-dev because there are some Chandler domain model  
questions at the bottom...

On Feb 9, 2007, at 8:24 AM, Randy Letness wrote:

> Jeffrey Harris wrote:
>> I'd like the conversion to/from icalendar from/to EventModification
>> records to handle no value in modifications smoothly.  I think  
>> this means:
>> - 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)?
>> Finally, I think we need a third (or a forth?) kind of null value for
>> EIM, there's already empty string vs. empty record vs. No Change,  
>> this
>> is "no attribute modification", or inherit from the master.
> Is this something Chandler needs?  Cosmo could just treat regular  
> null or "no change" as inherit from the master.
> -Randy

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?

In general I have had some confusion about mapping "None/Null" and  
"Empty" values to Chandler attributes.  Strings are straightforward:   
if we receive "None/Null", then we can actually remove the attribute  
from the item (our data model supports this); if we receive "Empty",  
then we assign "" to the attribute.  Other attribute types aren't so  
straightforward.  What does it mean to get an "Empty" value for an  
Integer attribute type?  Empty string is not a legal value for such a  
Chandler attribute.  Finally there are item-reference attributes like  
"Location", which within Chandler gets mapped to a separate location  
item rather than just stored as a string.  Does receiving "None/Null"  
for location mean we should remove the item's location attribute or  
should we just set it to None?  And what would we do with an "Empty"  
value in this case?  What does Cosmo do in all these cases?


More information about the chandler-dev mailing list