On Mar 13, 2007, at 7:59 AM, Grant Baillie wrote:
[cosmo-dev@ CC:ed, Reply-To: set to [EMAIL PROTECTED]
So, I've been looking through the Chandler domain model to see what
remains to be done w.r.t. EIM for Preview. Here's the laundry list
of stuff that's related to ContentItem/Note and Stamps: I'll send
out a separate email for the rest of the domain model (mainly,
collections), since those are more dump-and-reload than sharing
(morsecode) specific.
Feel free to chip in with stuff you think I've missed or
misunderstood, or to answer/ask questions.
I added some little codes to track what I thought the Cosmo impact
of the changes would be:
[√] == would need parallel change from Cosmo
[X] == no change needed from Cosmo (but needed for dump/reload
porpoises)
[?] == 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
[√] lastModification: An enumeration to say whether the last
change was
queued, edited, sent, updated. I should probably
add the 5th state, created, too.
modifiedFlags: This is a "bitfield" of the values in
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
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 = eim.field(eim.DecimalType(digits=20,
decimal_places=0))
[√] My understanding here is that Bug 7915 (and iCalendar
interoperability)
imply that we should have a separate ReminderRecord (or,
AlarmRecord, if
we're going with iCalendar-like syntax). What do people think
of that?
- EventRecord:
[√] icalParameters and icalProperties should probably move to
NoteRecord,
since VTODOs (and VJOURNAL, if anyone ever supports that :) can
have
them.
- EventRecord:
[√] # TODO: EventRecord fields need work, for example: 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
triage_recurrence
branch).
- {Event,Task}ModificationRecord:
[√] Do we need to think about supporting a 'modifies' field à 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/
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)?
Since this is going to the Cosmo list, for Server based sharing there
will be a need
to store the majority of information that makes up a MailStamp. I
have already
added the fields I believe are needed for server sharing. And I
filter out the ones I don't need for
peer to peer sharing.
I suspect the same information that is need to dump and reloading a
MailMessageRecord
will be required to share with Cosmo. The only info that would be
filtered out for Cosmo
sharing would be parentAccount, Bcc, and probably at least one other
field. Although
parentAccount and Bcc are the two that come to mind at the moment.
Hope that helps,
-Brian
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
