[Chandler-dev] Stamping and Dashboard domain-model questions

[Bryan Stearns]

(forgot to CC the list)

Grant,

I made the list below while trying to figure out upcoming tasks related 
to stamping and the dashboard in the UI... I'm not sure in whose 
bailliewick these reside, but I thought I'd bring them up with you to 
see if you'd considered them, or had opinions...

* What's the state of the discussion about whether we should use 
annotations for stamping? (many subquestions here: How do I know what 
stamps an item has? How will the attribute editor mechanism need to 
change? The attribute editor mechanism decides how to present an 
attribute based on its schema type; this attribute is specified as a 
simple name ("startTime") in definitions of instances of AEBlocks 
(detail view) and Columns (tables). Is it enought to simply change to a 
dotted python class name (eg, "osaf.pim.CalendarEventMixin.startTime"?)

* What of attribute redirection remains at the domain-model level? The 
dashboard spec calls for editing of attribute-redirected columns like 
Who and Date - how is this implemented in a world where duck-typing no 
longer works for stamped attributes?

* Does column sorting always imply another repository index on each 
user-visible collection? It seems like either the comparison function 
needs to take into account all the possible conditions that affect 
sorting (so the function for the communications column needs to consider 
whether the item is stamped as communications, and if it is, 
read/unreadness, draft-ness, 
inbound/outbound-edited/outbound-queued/outbound-sent, whether it needs 
a reply, whether it's first-time or updated, error state, and triage 
status; the Date column depends on tickler time and condition, start & 
end datetime if stamped as event, date last modified, date sent if 
stamped as comm, and date created), and the index needs to be updated 
(and collection notifications need to fire) if any of these underlying 
conditions change. (Having date-last-modified in this list means there 
are going to be a lot of potential index updates happening!)

* The Dashboard spec says the triage column is sorted Now, Later, Done, 
and within Done by the date that the Done status was set. (This implies 
a triageValueChangedDate attribute - is there a way to get the 
repository to enforce updating this value when the triage attribute is 
changed -- I'm guessing we'll need some similar repository-level 
mechanism to set and update the date-created and date-last-modified 
attributes.

* Further, the triage-status column isn't supposed to have user changes 
take effect until the user hits a Purge button; this seems to imply that 
we'll need a separate attribute to store the pending triage state, and 
copy it to the real triage attribute when the user hits the button. Are 
there issues around conflicts that we need to deal with here? (What 
happens if triage status changes automatically between the user's edit 
and the user's Purging?)

In the event-updates realm, I'm not sure how to address how to address a 
couple of requirements:
* When the user edits a received emailevent, the Send button is supposed 
to be enabled. At what level should this happen? (It seems bad to 
require that anything that changes an item attribute also consider 
whether that change constitutes a sendable update, but I'm not sure we'd 
implement it at the repository level, either, given that selecting an 
item in the UI currently changes it.)
* The stamping spec implies that the user-visible To/From/CC fields 
aren't necessarily the To/From/CC fields in the RFC822 message (though 
it seems to imply that the Sender attribute is the From on the email)... 
How are these fields managed for items that could be coming & going at 
the same time?

...Bryan