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

[Brian Kirsch]

On Mar 13, 2007, at 7:59 AM, 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 =20=

> remains to be done w.r.t. EIM for Preview. Here's the laundry list =20
> of stuff that's related to ContentItem/Note and Stamps: I'll send =20
> out a 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 =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 :) 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 =20
> least for
>        dump/reload).

At this point I see no reason to pass around rfc2822Message LOB's.

In  fact, the rfc2822Message attribute is no longer being used by =20
Chandler for Preview
since there was no need to store this information. Not saving the =20
entire message
bodies (including large attachments) saves Repository space and =20
increases Chandler
performance.



> 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-=20
> MailStamp
>        parts of dump/reload (e.g. account info, mainly)?
>

I have already implemented the MailMessage Record (in my local SVN) =20
for sending and receiving EIMML.
Most of the fields are actually filtered out. Really, all that is =20
needed in a MailMessageRecord
for Edit / Update are the addressing fields, the displayName, and the =20=

Body. All the other attributes are
client specific (headers, parentAccount, InReplyTo, etc) and are =20
assigned by the Mail Service.

I am planning on starting dump and reload of MailMessageRecords and =20
Accounts on Wednesday.


> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev