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

[Grant Baillie]

[cosmo-dev@ CC:ed, Reply-To: set to chandler-dev@]

So, I've been looking through the Chandler domain model to see what =20
remains to be done w.r.t. EIM for Preview. Here's the laundry list of =20=

stuff that's related to ContentItem/Note and Stamps: I'll send out a =20
separate email for the rest of the domain model (mainly, =20
collections), since those are more dump-and-reload than sharing =20
(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 of =20=

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 of =20=

that?

- EventRecord:
     [=C3] icalParameters and icalProperties should probably move to =20
NoteRecord,
     since VTODOs (and VJOURNAL, if anyone ever supports that :) can =20
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/cc/=20
bcc; I'm
        not sure if we need the complete rfc2822Message LOB (at least =20=

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)?