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
