On Feb 11, 2007, at 10:18 PM, Philippe Bossut wrote:
Hi Morgen,
This sounds great! Hope Reid will chime in if he has issues. I just
have one question:
Morgen Sagen wrote:
field -- a string indicating which field was changed
What's the granularity of that "field"? I understand it's not
mapping attributes 1:1 .
The granularity of "field" can be a spectrum ranging from the entire
item, down to an individual EIM field. At the moment, a Conflict's
field granularity *is* the entire item, but soon it will be an EIM
field. The currently defined EIM fields essentially map 1:1 to
Chandler attributes. There are several EIM record types defined (in
sharing/model.py) which correspond to the various Stamps:
ItemRecord:
- title (displayName)
- triageStatus
- triageStatusChanged
- lastModifiedBy
- createdOn
NoteRecord
- body
- icalUid
- reminderTime
TaskRecord
(Doesn't add any fields)
EventRecord
- dtstart
- dtend
- location
- rrule
- exrule
- rdate
- exdate
- status (transparency)
MailMessageRecord
(TBD)
The records representing event modifications/exceptions are also
being discussed.
I said that the granularity of a Conflict object's "field" is a
spectrum -- that's because if we need to, we could add the ability
for the code behind the conflict API to "link" two or more fields
together such that they can only be rendered/applied/discarded as a
unit. We're not sure we have any fields which require this yet.
~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
