Thanks, Grant - I'm about to send out another list of issues resulting
from a detailed read of the dashboard spec, so maybe we can have a
bigger discussion that combines these issues with those, once alpha3's
in the bag.
...Bryan
Grant Baillie wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
