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).
At this point I see no reason to pass around rfc2822Message LOB's.
In fact, the rfc2822Message attribute is no longer being used by
Chandler for Preview
since there was no need to store this information. Not saving the
entire message
bodies (including large attachments) saves Repository space and
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-
MailStamp
parts of dump/reload (e.g. account info, mainly)?
I have already implemented the MailMessage Record (in my local SVN)
for sending and receiving EIMML.
Most of the fields are actually filtered out. Really, all that is
needed in a MailMessageRecord
for Edit / Update are the addressing fields, the displayName, and the
Body. All the other attributes are
client specific (headers, parentAccount, InReplyTo, etc) and are
assigned by the Mail Service.
I am planning on starting dump and reload of MailMessageRecords and
Accounts on Wednesday.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
