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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
