[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?
~morgen
More information about the cosmo-dev
mailing list