On 21 Mar, 2007, at 14:58, Katie Capps Parlante wrote:
> Just to follow up, have all of these items been resolved? In =20
> particular, did Morgen's "Proposed EIM record changes" capture =20
> everything that Cosmo team needs to know?
>
> http://lists.osafoundation.org/pipermail/cosmo-dev/2007-March/=20
> 003242.html
So far as I can tell, verything I marked as [=C3] or [?] is either =20
covered by Morgen's proposal, has been determined to be invalid, or =20
was decided in the above thread.
--Grant
>
> 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 =20
>> what remains to be done w.r.t. EIM for Preview. Here's the laundry =20=
>> list of stuff that's related to ContentItem/Note and Stamps: I'll =20
>> send out a separate email for the rest of the domain model =20
>> (mainly, collections), since those are more dump-and-reload than =20
>> sharing (morsecode) specific.
>> Feel free to chip in with stuff you think I've missed or =20
>> misunderstood, or to answer/ask questions.
>> I added some little codes to track what I thought the Cosmo impact =20=
>> of the changes would be:
>> [=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)
>> - Morgen sent out an earlier email about triage in ItemRecord
>> - Unsupported fields in ItemRecord:
>> [X] error (a string)
>> [?] read
>> [?] needsReply
>> [=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.
>> modifiedFlags: This is a "bitfield" of the values in =20
>> 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 =20
>> 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 =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?
>> - EventRecord:
>> [=C3] icalParameters and icalProperties should probably move to =20=
>> NoteRecord,
>> since VTODOs (and VJOURNAL, if anyone ever supports that :) =20
>> can have
>> them.
>> - EventRecord:
>> [=C3] # TODO: EventRecord fields need work, for example: rfc3339 =20=
>> 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 =20
>> triage_recurrence
>> branch).
>> - {Event,Task}ModificationRecord:
>> [=C3] Do we need to think about supporting a 'modifies' field =88 =
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/=20
>> cc/bcc; I'm
>> not sure if we need the complete rfc2822Message LOB (at =20
>> least for
>> dump/reload). Probably this is more Mr Kirsch's area, but I =20=
>> can take
>> a look if need be. Also, Brian, were you working on the non-=20=
>> 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
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev