On Mar 13, 2007, at 10:59 AM, Grant Baillie wrote:
[√] == would need parallel change from Cosmo
[X] == no change needed from Cosmo (but needed for dump/reload
porpoises)
[?] == unsure if this requires changes (i.e. part of morsecode)
[X] error (a string)
Actually, the "error" attribute on ContentItem isn't used by the
sharing layer (I use sharing.Share.error). Kirsch, does the mail
framework use this attribute? Otherwise we should remove it from
ContentItem.
[?] read
I recommended to Stearns that he set an item to "unread" whenever the
sharing layer has just applied incoming changes to an item. However,
I just realized that this isn't what we want for dump/reload. We
actually want the read/unread state to come from the EIM records
themselves when reloading. Stearns: if we instead set the item to
"unread" just *before* recordset_conduit applies the incoming changes
(instead of just afterwards), this will work the way we need it --
I'll add an EIM field for "read" to a dump/reload specific record
type, and when that gets applied it will overrule the explicit
setting of "unread".
[?] needsReply
Anyone know about "needsReply"? Is this something we just want for
dump/reload?
[√] lastModification: An enumeration to say whether the last
change was
queued, edited, sent, updated. I should probably
add the 5th state, created, too.
Ok, I'll add lastModification to the ModifiedByRecord, as a field
named "action", using these numeric codes:
"edited":100, "queued":200, "sent":300, "updated":400, "created":500
modifiedFlags: This is a "bitfield" of the values in
lastModification.
Does modifiedFlags need to be shared/dumped?
- NoteRecord currently has:
# Note.reminders? (Translator not implemented yet)
reminderTime = eim.field(eim.DecimalType(digits=20,
decimal_places=0))
[√] My understanding here is that Bug 7915 (and iCalendar
interoperability)
imply that we should have a separate ReminderRecord (or,
AlarmRecord, if
we're going with iCalendar-like syntax). What do people think
of that?
Is that what the DisplayAlarmRecord is for? Actually I don't
remember the relationship between Note.reminderTime field and
DisplayAlarmRecord.
- EventRecord:
[√] icalParameters and icalProperties should probably move to
NoteRecord,
since VTODOs (and VJOURNAL, if anyone ever supports that :) can
have
them.
Ok I will move these to NoteRecord. Jeffrey, is that okay with you?
Currently these are filtered out and not sent to Cosmo.
- EventRecord:
(when exporting event modifications)
[?] # TODO: yield a TaskModificationRecord if appropriate
The ...ModificationRecords are all going away.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
