I've been meaning to reply to this.. Grant's message has finally
prompted me to write something up:
I followed some of the conversation in IRC regarding stamping items
using annotations (see
http://kumu.osafoundation.org/~ircd/irc-logs/chandler.log.20060504
around [14:51])
I think that the actual stamping mechanism we use is orthogonal to the
Annotation mechanism.. because no matter how it is implemented it all
comes down to keeping a list of 'related' or 'stamp-related' items in a
well known attribute or attributes. Using schema.Annotation just
separates that well known attributes into something with a namespace.
But that's a good thing.
That said, I want to +1 grant's recommendation that zope.interface is
investigated - either as an alternative, or as a supplement to what is
being proposed here. As I understand zope.interface, it provides a
programmatic (i.e. runtime-evaluated) way of implementing a notion like
'stamping' - which has the advantage of being able to specialize
certain types of stamps (for instance, 'stamping' an event as an
communication is not so much about object identity as it is about
association of communication objects like e-mail messages with their
original event.. so zope.interface would allow Event objects to have
specialized Event -> Communication behavior)
So I guess I see some of this proposal as being how we would persist the
stamped-ness of a set of objects, with some handwaving (as you said :))
about some of the issues (like bi-directionality vs multi-directionality
of stamp relationships) and zope.interface addressing some of the issues
of how we would traverse/create/discover stamp-relationships with
handwaving about how it would actually be persisted. (i.e. the zope
adapter registry? is that built up at runtime or persisted somehow in
the repository?)
Alec
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
