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

[Bryan Stearns]

(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
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev