[Cosmo-dev] ContentItem sharing (Was Re: [Chandler-dev] What attributes get shared over EIM)

[Morgen Sagen]

On Mar 13, 2007, at 10:59 AM, Grant Baillie wrote:
>   [=C3] =3D=3D would need parallel change from Cosmo
>   [X] =3D=3D no change needed from Cosmo (but needed for dump/reload =20=

> porpoises)
>   [?] =3D=3D 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 =20
sharing layer (I use sharing.Share.error).  Kirsch, does the mail =20
framework use this attribute?  Otherwise we should remove it from =20
ContentItem.

>   [?] read

I recommended to Stearns that he set an item to "unread" whenever the =20=

sharing layer has just applied incoming changes to an item.  However, =20=

I just realized that this isn't what we want for dump/reload.  We =20
actually want the read/unread state to come from the EIM records =20
themselves when reloading.  Stearns: if we instead set the item to =20
"unread" just *before* recordset_conduit applies the incoming changes =20=

(instead of just afterwards), this will work the way we need it -- =20
I'll add an EIM field for "read" to a dump/reload specific record =20
type, and when that gets applied it will overrule the explicit =20
setting of "unread".

>   [?] needsReply

Anyone know about "needsReply"?  Is this something we just want for =20
dump/reload?

>   [=C3] lastModification: An enumeration to say whether the last =20
> 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 =20
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 =20
> lastModification.

Does modifiedFlags need to be shared/dumped?

> - NoteRecord currently has:
>     # Note.reminders?  (Translator not implemented yet)
>     reminderTime =3D eim.field(eim.DecimalType(digits=3D20, =20
> decimal_places=3D0))
>
>     [=C3] My understanding here is that Bug 7915 (and iCalendar =20
> interoperability)
>     imply that we should have a separate ReminderRecord (or, =20
> AlarmRecord, if
>     we're going with iCalendar-like syntax). What do people think =20
> of that?

Is that what the DisplayAlarmRecord is for?  Actually I don't =20
remember the relationship between Note.reminderTime field and =20
DisplayAlarmRecord.

>
> - EventRecord:
>     [=C3] icalParameters and icalProperties should probably move to =20=

> NoteRecord,
>     since VTODOs (and VJOURNAL, if anyone ever supports that :) can =20=

> have
>     them.

Ok I will move these to NoteRecord.  Jeffrey, is that okay with you?  =20=

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.