Hi, Katie et al
Apologies for the delay in this reply: It has been sitting half-
composed in my drafts for a while, but I didn't get around to
finishing it during the fun and excitement of sprint week. Overall, I
like the general idea of maintaining dynamicity without having to
have the Chandler UI deal with arbitrary items all over the place.
As I mentioned in passing the other day, the adapter terminology is
also used by zope.interface, code Chandler already links against (as
twisted depends on it). For some docs, see the installed
zope.interface files README.txt, human.txt (sic), adapter.txt and the
python docstrings (in declarations.py, at least). You can also browse
them in zope's svn repository @ <http://svn.zope.org/Zope3/trunk/src/
zope/interface/>.
I'm not the greatest expert on zope.interface, but the docs I've
looked at indicate it has API for discoverability, flexible
adaptation, stamping (i.e. per-instance adoption of interfaces --
"cluster of attributes" in your terminology) and unstamping (i.e. per-
instance removal of interfaces). Assuming this would be a good route
to follow, I haven't really thought about how to get any of this to
persist.
So far as open issues go:
- Are you saying that we would keep the current Kind composition
approach to stamping under the covers? I guess we need that to have
existing Kind collection code/indexes work. In general, in the
somewhat more vague world of contexts/data adapters, it might be
tricky to maintain the various and sundry indexes Chandler needs for
performance reasons.
- I'm not really sure how much work it would be to maintain
recurrence in this world. Part of this is it makes my head hurt when
I start to think about recurring stamped items: I can see cases where
they would be really useful, and others where they would be
confusing. On a slight tangent, it seems to me that, long-term, it
would be good to have recurrence be less tied to event-ness. Besides
making stamping conceptually easier IMHO, the current scheme has
shown some limitations in the face of Morgen & Andi's background sync
(a.k.a. view merging) implementation. Also, having a more stamping/
annotation-like recurrence implementation under the covers would make
future directions (like recurring tasks, books, or showing birthdays
on the calendar) easier.
--Grant
On May 4, 2006, at 15:59, Katie Capps Parlante wrote:
I'll start with the punchline:
I think we should implement stamping using annotations
Or to be more specific, a Stamp subclass of Annotation.
What follows is a meandering argument touching on displayName, what
attributes are displayed in what columns and other fun snakes we've
been wrestling for some time. I will also inflict terminology on
you, including "information item" (which I think is really a
"content item") and "context" (which bears a passing resemblance to
a "view" in mvc).
From the user's perspective, we will have three different ways of
associating items with each other:
1. collection membership (these events are all in my work calendar)
2. linking one item to another (this person wrote that email, and
conversely that email was written by this person)
3. clusters/threads of items (these email items represent a
conversation)
After several iterations, we've worked out something for #1,
although we'll get more sophisticated with mechanisms to build new
collections: tagging/labels, rule filters, etc.
Surprisingly (to me anyway), we're not yet really using #2 in a way
that is visible to the user. We will eventually. When "Locations"
become first class "information items" in the ui, and when we add
contacts to the ui, the user will see this kind of relationship
show up in a more visible way. The user will (eventually) be able
to navigate from one linked item to another, and each "information
item" will be able to be displayed in a detail view.
We haven't discussed how to model #3 (or at least I haven't), but
probably should get our heads around it in the near future. One of
the decisions we have to make is whether or not this feature
belongs in 1.0 (the working hypothesis is that we do want it for a
useable beta).
Stamping is a semantically different affordance from #1, #2, or #3.
To the end user, adding a stamp to an item:
- adds a cluster of attributes to that item
(events have start times, end times)
- types the item so that it can appear in particular contexts
(events show up on calendars, tasks show up on task lists,
events, tasks, notes and communication items show up in dashboards)
- adds behavior to manage the data properly
(make sure start/end/duration are in sync, recurrence management)
The "information item" with multiple stamps is one item to the user.
- The item shows up once in search results
- The item shows up as one item in tables (dashboard view, task list)
- The item is displayed as one thing in the detail view
Linked items will logically be two different items to the user, and
the user will (eventually) have affordances to navigate between
them. If a "Location" was a separate "information item", the user
would be able to look at a collection of them and be able to view/
edit a location from its own detail view. (If we weren't going to
enable these feaures, we probably wouldn't want to model "Location"
as a "ContentItem" imho). A stamped thing can still be linked to
other things (including other stamped things).
Mimi talked about contexts -- a "calendar event" stamp enables the
item to show up in the calendar view context. An quick inventory of
"contexts" we currently have in Chandler:
- detail view
- calendar summary view
- task list
- mail list
- dashboard ("all")
- sidebar
If we examine these contexts, the calendar summary view is a
context that displays things with calendar event stamps. We can
think of the calendar event stamp as the adapter that allows the
item to be displayed in the calendar summary view -- the calendar
summary view needs the attributes defined by the stamp to know how
to display the item.
I think one of the central tensions in our early thinking was an
assumption that we needed a general purpose table summary view to
work in all contexts, and that the individual item would determine
how it was displayed in that general summary view table. We
originally thought *all* items should display properly in this
general information manager table, including blocks, menus, twisted
tasks, etc. This general information manager table was the
inspiration for things like "displayName". I think we've discovered
that we really want more specific "contexts" that can have some
expectations about the items displayed in them, including domain
specific expectations about the APIs. We could still have a
"general information manager" context that was able to display any
item in the system (for a repository viewer), but that general
information manager doesn't have to be made to meet the needs of a
dashboard view. Yes, they will share a wx table under the hood, as
well as chandler specific infrastructure like attribute editors.
The sidebar context displays collections.
Right now, the task list, mail list, and dashboard contexts behave
in basically the same way, but this may not always be true. These
contexts are pim (as in event-task-email) specific. The dashboard
context is similar to a general information manager, in that it is
interested in items with different stamps/adapters: tasks, events,
notes, communications. The dashboard can have context specific
logic to determine how to populate "who", "what", etc. columns.
Alternatively, items that want to show up in the dashboard context
could provide a "dashboard" adapter, and this adapter could
determine how to populate "who", "about", etc.
Now, what mechanism do we have to implement a "data adapter"?
Annotations, anyone?
Calendar eventness could be defined in an annotation -- a data
adapter for the item to have "calendarness", including the ability
to show up in calendar contexts. Annotations also allow methods
that we can use to handle behavior -- presumably we'd need this to
implement recurrence and other code intended to keep data
consistent. (As opposed to behaviors that really belong in other
layers).
The detail view is another example of a "general purpose" context,
in that it has to display any "information item". Detail views and
tables both use attribute editors, which are themselves "contexts".
In this case, the "contexts" display attributes and not items. We
could use the adapter pattern to solve certain problems when the
detail view has to make a decision about which attributes to
display -- "information items" could have a context specific detail
view adapter. Alternatively, the detail view could have specific
contextual knowledge about making those choices (as we have today,
different views are selected based on the item).
Thoughts on open problems:
- Search/query efficiently on attributes: would work as it does on
any item (no traversing links between items), as annotations add
attributes to the kind under the hood -- the attributes are all on
one "item".
- kinds: annotations don't add kinds, and we have a lot of
infrastructure right now based on the kind. Could we add kinds to
the item? Any other ideas?
- recurrence: not sure. Grant? Jeffrey? could this be made to work?
- unstamping then restamping: presumably the stamp subclass could
implement this behavior, marking the attributes or whatever.
- stamp discovery: we'd need the ability to get a list of stamps
that a given item had. As PJE pointed out, if you are not looking
at an object through the lens of its adapter, it doesn't get the
adapter behavior. I think this could be ok, as long as we have the
ability to discover stamps/adaptors and are conscious of using them
appropriately. Any thoughts on problems this would cause?
- overlapping attributes: annotations provide namespaces to
distinguish between attributes, but that doesn't solve the whole
problem. The detail view context needs to know how to make a
decision about which attribute to use. Perhaps this is knowledge
that a "detail view adapter" knows, or perhaps this is knowledge
that the particular detail view knows.
So, that was too long and handwavy and incomplete to be a real
proposal, but I wanted to throw it out there for reactions. Thoughts?
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
