[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)?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
