(I answered the questions I knew about, below ...Bryan)
Morgen Sagen wrote:
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.
I know bkirsch will answer, but I think the answer's "yes"; however, I'm
concerned that sharing doesn't set an error attribute on the item
(otherwise, how will the communications state icon know to show error
status?)...
(A brief IRC exchange between Morgen, Grant and I reveals that there
probably is a disconnect in this area...)
[?] 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".
OK, I've made that change in my local tree.
[?] needsReply
Anyone know about "needsReply"? Is this something we just want for
dump/reload?
It's a flag manipulated by the user (by clicking in the communications
state column in the dashboard, which cycles through
read/unread/needs-reply states, manipulating the "read" and "needsReply"
attributes. Yes, it should be dumped and reloaded.
[√] 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.
_______________________________________________
cosmo-dev mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
