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

[Ted Leung]

Brian and Randy, does this cover what you need to know?

Ted

On Mar 21, 2007, at 4:47 PM, Grant Baillie wrote:

>
> 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 =20
>>> laundry list of stuff that's related to ContentItem/Note and =20
>>> Stamps: I'll send out a separate email for the rest of the domain =20=

>>> model (mainly, collections), since those are more dump-and-reload =20=

>>> than 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 =20
>>> impact 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: =20
>>> 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 =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 =20
>>> I can take
>>>        a look if need be. Also, Brian, were you working on the =20
>>> 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
>>
>> _______________________________________________
>> 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