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

[Brian Kirsch]

On Mar 15, 2007, at 6:10 AM, Morgen Sagen wrote:

>
> 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.

I was using a DeliveryError item which is part of the mail schema. =20
However, I changed my code locally to now use the ContentItem.error =20
attribute.
And when I get errors on sends, I do see the error text in the detail =20=

view which is cool.

IMO, We should have a central way to set transport errors on items =20
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 =20
> the sharing layer has just applied incoming changes to an item.  =20
> However, I just realized that this isn't what we want for dump/=20
> reload.  We actually want the read/unread state to come from the =20
> EIM records themselves when reloading.  Stearns: if we instead set =20
> the item to "unread" just *before* recordset_conduit applies the =20
> incoming changes (instead of just afterwards), this will work the =20
> way we need it -- I'll add an EIM field for "read" to a dump/reload =20=

> specific record type, and when that gets applied it will overrule =20
> the explicit 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 :) =20
>> can have
>>     them.
>
> Ok I will move these to NoteRecord.  Jeffrey, is that okay with =20
> 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