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 [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
I've got changes for this in the triage-recurrence branch; I hope
to merge these into the trunk today or tomorrow.
- 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).
Most of the autotriage mechanism is done in the triage-recurrence
branch; I haven't added the calls to actually do autotriaging when
an updated item is received; I'm planning on doing it soon, though
I dunno whether it'll be before the merge.
- {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)?
Not quite what you asked, but I have a separate change (not in the
branch, not checked in), that adds an "originators" attribute to
MailStamp, displayed/edited with the other email addresses in the
detail view as "From"; the existing fromAddress attribute is
manipulated by the byline Send As mechanism.
There's more required that I haven't done yet (displaying the send-
as address value until the user puts a custom value in the
originators/From field;
copying valid addresses from originators to CC on reply,
The mail service takes care of all outbound mail message assignments.
The UI layer should just ensure that the correct Chandler fields are
filed in such as the Chandler From:. The mail service will then
translate the Chandler values to RFC2822 addressing fields when sending
the Item.
putting the originators list in the body prefix for non-Chandler
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
view of Chandler messages.
I haven't looked at the mail spec or ongoing discussion in detail,
but I don't know whether the byline spec requires anything more
than what's there now.
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
