On Mar 15, 2007, at 6:10 AM, 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 was using a DeliveryError item which is part of the mail schema.
However, I changed my code locally to now use the ContentItem.error
attribute.
And when I get errors on sends, I do see the error text in the detail
view which is cool.
IMO, We should have a central way to set transport errors on items
now that there is P2P and Server based sharing of the same items.
[?] 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
