Hi, Brian
Thanks for the detailed questions, and sorry it's taken me a while to
get back to you: I've been busy with α3 stuff in the interim. My
answers, or initial thoughts more than answers, are inline below.
--Grant
PS: Believe it or not, that's the first time I've seen that pun on
'bailiwick', really. Maybe in the past I've tended not to associate
with people who use such fancy words :)
On Jun 12, 2006, at 13:13, Bryan Stearns wrote:
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?
Well, that's being explored. I wrote some very simple code to
implement what was discussed on chandler-dev@, but hadn't gotten as
far as converting over any of the existing mixins. For the next week
or so, this is mostly on hold: my main focus right now is recurrence
work for 0.7α3.
(many subquestions here: How do I know what stamps an item has?
You can just ask an item for its stamps (as in pje's email <http://
lists.osafoundation.org/pipermail/chandler-dev/2006-May/
005911.html>): Something like
Stamp(item).stamps
should be what works.
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"?)
A dotted attribute name should work, although maybe it'll be worth
thinking about having another way. (i.e. maybe the dotted name is
exposing an implementation detail of annotations).
* 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?
I believe we're moving away from redirected (and duck-typed)
attributes, i.e. fixing which attributes are displayed in which views
(à la <http://lists.osafoundation.org/pipermail/chandler-dev/2006-
March/005388.html>, and related). However, this raises a different
question, which is that if, as suggested in that thread, we move to
using onValueChanged() to update various UI-related attributes (e.g.,
"DashboardWho"), and we have stamping as annotations, then some
onValueChanged() implementation needs to iterate over stamp classes.
* 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!)
As I understand it, sorted tables require an index (or would be
cripplingly slow for large collections). But, cases like this (and
some of the subsequent) lead me to think we maybe need the ability to
index (and update) computed attributes (the repo version of Python
properties). Something else to think about is that maybe we could
leverage subindexes in some way: i.e. have a master index for all
table-sortable properties of all items, and have the different table
views use subindexes. That said, I know little enough about
subindexes that I don't know if they will be a magic bullet here.
* 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.
I don't know of an 'update attribute x when any of y, z, ... has
changed' mechanism, other than hand-coding an onValueChanged() in the
Python class. (I guess monitors could do this, but certainly having a
monitor per ContentItem is overkill).
* 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?)
Hmm.... I hadn't seen the Purging feature: That looks pretty tricky
in our current auto-reindex-columns paradigm.
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 information as to what attributes contribute toward sendability
should live at the domain model layer, but it doesn't seem right to
be tracking changes in sendability for all items. Could the UI
(detail view) attach a monitor if it's a communication item?
* 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?
I'll have to get back to you on that one after I go through that part
of the stamping spec in more detail...
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
