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

[Katie Capps Parlante]

Just to follow up, have all of these items been resolved? In particular, 
did Morgen's "Proposed EIM record changes" capture everything that Cosmo 
team needs to know?

http://lists.osafoundation.org/pipermail/cosmo-dev/2007-March/003242.html

Cheers,
Katie

Grant Baillie wrote:
> [cosmo-dev@ CC:ed, Reply-To: set to chandler-dev@]
> 
> So, I've been looking through the Chandler domain model to see what 
> remains to be done w.r.t. EIM for Preview. Here's the laundry list of 
> stuff that's related to ContentItem/Note and Stamps: I'll send out a 
> separate email for the rest of the domain model (mainly, collections), 
> since those are more dump-and-reload than sharing (morsecode) specific.
> 
> Feel free to chip in with stuff you think I've missed or misunderstood, 
> or to answer/ask questions.
> 
> I added some little codes to track what I thought the Cosmo impact of 
> the changes would be:
> 
>   [√] == 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)
> 
> - Morgen sent out an earlier email about triage in ItemRecord
> 
> - Unsupported fields in ItemRecord:
> 
>   [X] error (a string)
>   [?] read
>   [?] needsReply
>   [√] lastModification: An enumeration to say whether the last change was
>                     queued, edited, sent, updated. I should probably
>                     add the 5th state, created, too.
>   modifiedFlags: This is a "bitfield" of the values in lastModification.
> 
> 
> - In the ItemRecord code
>     # TODO: see why many items don't have createdOn
>     [X] I'll look at this
> 
> - ItemRecord (importing triage):
>     [X] # TODO: do something with auto
> 
> - In the NoteRecord code: there are TODOs in the import & export methods:
>     ...
>     [?] # TODO: REMOVE HACK: (Cosmo sends None for empty bodies)
> 
>     I'm not sure what this is about ...
> 
> - 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?
> 
> - EventRecord:
>     [√] icalParameters and icalProperties should probably move to 
> NoteRecord,
>     since VTODOs (and VJOURNAL, if anyone ever supports that :) can have
>     them.
> 
> - EventRecord:
>     [√] # TODO: EventRecord fields need work, for example: rfc3339 date 
> strings
> 
> - EventRecord:
>     (when exporting event modifications)
>     [?] # TODO: yield a TaskModificationRecord if appropriate
> 
> - EventRecord needs support for autoTriage when that's checked in
>     [?]
>   (possibly this has been taken care of in the Chandler triage_recurrence
>   branch).
> 
> - {Event,Task}ModificationRecord:
>    [√] Do we need to think about supporting a 'modifies' field à la
>        iCalendar RANGE (IIRC)? It's possible Chandler will support
>        THISANDFUTURE more robustly (Currently, we just make a new
>        recurring series in this case, which is probably what Cosmo
>        does, too). Maybe this could just be a future addition to the
>        schema?
> 
> - MailMessageRecord:
>    [?] I believe there are more fields needed besides subject/to/cc/bcc; 
> I'm
>        not sure if we need the complete rfc2822Message LOB (at least for
>        dump/reload). Probably this is more Mr Kirsch's area, but I can take
>        a look if need be. Also, Brian, were you working on the 
> non-MailStamp
>        parts of dump/reload (e.g. account info, mainly)?
> 
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev