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

[Brian Kirsch]

Hi Byan,
See comments inline.


On Mar 13, 2007, at 8:31 AM, Bryan Stearns wrote:

> Comments inline below...
>
> 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
> I've got changes for this in the triage-recurrence branch; I hope =20
> to merge these into the trunk today or tomorrow.
>>
>> - 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 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).
> Most of the autotriage mechanism is done in the triage-recurrence =20
> branch; I haven't added the calls to actually do autotriaging when =20
> an updated item is received; I'm planning on doing it soon, though =20
> I dunno whether it'll be before the merge.
>>
>> - {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 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)?
> Not quite what you asked, but I have a separate change (not in the =20
> branch, not checked in), that adds an "originators" attribute to =20
> MailStamp, displayed/edited with the other email addresses in the =20
> detail view as "From"; the existing fromAddress attribute is =20
> manipulated by the byline Send As mechanism.
>
> There's more required that I haven't done yet (displaying the send-=20
> as address value until the user puts a custom value in the =20
> originators/=46rom field;

> copying valid addresses from originators to CC on reply,

The mail service takes care of all outbound mail message assignments. =20=

The UI layer should just ensure that the correct Chandler fields are
filed in such as the Chandler From:. The mail service will then =20
translate the Chandler values to RFC2822 addressing fields when sending
the Item.

> putting the originators list in the body prefix for non-Chandler =20
> users, etc). This will get finished after the branch is merged.

No need to do this as well. I already have code to build the Mail GUI =20=

view of Chandler messages.
>
> I haven't looked at the mail spec or ongoing discussion in detail, =20
> but I don't know whether the byline spec requires anything more =20
> than what's there now.
>
> ...Bryan
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev