[Chandler-dev] stamping as annotations?

[Grant Baillie]

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