[Design] Re: Design Digest, Vol 15, Issue 10

[Donn Denman]

Phillip,

I'm glad to see you are jumping in to the Chandler design discussions, 
and stamping seems like a great place to start.  I'm sure the other 
design folks will want to address many of the interesting ideas you've 
shared with us.  I'd like to fill in some of the history of how the 
Chandler Engineering team decided to implement stamping using the 
"morph" model instead of the "link" model.

In May of 2004 we were doing early work on the 0.4 release of Chandler, 
and I was working on the Detail View.  The Detail View includes the 
Markup Bar, which has the stamping buttons, and I decided that we 
needed to implement stamping right away because it's such a central 
part of the UI workflow.  We had just the beginnings of an 
implementation at that time, and the implementation was actually 
following the "link" model that you discuss below.

On May 18th the Design team and the Development team had a big meeting 
to talk about the some of the requirements for stamping.   Chao or Mimi 
put up a wiki page that had a big grid that showed all the attributes 
that apply to the various Kinds.  I wish I could find this wiki page to 
give you a reference.  Mimi described the "bag of attributes" model 
that she was working with - that stamping an item adds a collection of 
attributes to that item.  We saw that in general, the attributes were 
independent; you could add a bunch of attributes without risking a 
collision with existing attributes.  But there were a couple of 
wrinkles:
    1) each kind had a base set of attributes (e.g. the body) in common,
    2) many kinds had attributes that had different names, though they 
served a similar purpose
    3) there was a special case: when combining an Event with a Task, 
there's an additional bag of attributes needed for the synergy between 
the kinds
I wrote up my notes on the meeting and posted them on the wiki here:
http://wiki.osafoundation.org/bin/view/Chandler/AttributeConflicts
It seemed clear to me that adding a "bag of attributes" to an item was 
following the "morph" model rather than the "link" model.

For about the next month we mulled over the idea of using the morph 
model instead of the link model.  It seemed to me and John that the 
morph model was clearly cleaner.  With the linked model, you get into a 
lot of situations where the linked items are supposed to share an 
attribute (like the body), but actually have multiple copies of the 
attribute, one on each item.  Then you get into the business of trying 
to keep them in sync.  Also, if multiple items are supposed to be 
strongly linked, and act like a single item, then you have added 
complications whenever you do an operation on one of those items, like 
delete it; do you delete the linked items too?  We were still mulling 
over the choice of linking or morphing, and we knew we didn't have the 
underlying support in the repository for morphing.

In June, Lisa came up with a list of specific use cases that could tell 
us which model was a better fit for the UI design.  She sent out this 
email on June 11th:
----------------------
I'm trying to sort out the model for stamped items -- how to represent 
them in the API (content model), then how to represent them in storage 
(data model).  To this end, I've been checking out the GUI plans (how 
stamped items appear), and Donn forwarded me some email discussion on 
stamped items, but I'd still like to know more about how they should 
behave.

     * Does a stamped item have two creation dates, or one?
     * Does a stamped item always have one ACL, or can it have N?
     * Is a stamped item always shared as a whole thing?
     * Does a stamped item have one body or two?
           o With an email stamped as a task, the email body could 
become the body of the task-like stamped item. Or, the email body could 
remain the email body, and have a separate task body.
     * Can you ever delete one aspect of a stamped item? Or is this 
"unstamping"?
     * Can you ever separate a stamped item into two items?
     * Does a stamped item have a single version history, or can you 
follow separate version histories for each aspect?
     * Normally a task-stamped email shows up as a task. Does a search 
hit on the email aspect of a task-stamped email show up as a task too?

It's Ok if we'd like some of these to behave as if the stamped item 
were one thing, and others to behave the other way -- let's figure out 
what the user would like to happen first, then see if we can make it 
happen without being too confusing :)

Thanks,
Lisa
-------------------

Mimi replied on the 12th:

-------------------
Hi Lisa,

I'll take a stab at answering your questions. Mitch, feel free to jump 
in if I'm not accurately representing what we've discussed.

On Jun 11, 2004, at 5:09 PM, Lisa Dusseault wrote:

> I'm trying to sort out the model for stamped items -- how to represent 
> them in the API (content model), then how to represent them in storage 
> (data model).  To this end, I've been checking out the GUI plans (how 
> stamped items appear), and Donn forwarded me some email discussion on 
> stamped items, but I'd still like to know more about how they should 
> behave.
>
>     * Does a stamped item have two creation dates, or one?
An email that has been stamped as a task is represented to the user as 
the following:
Email (version1)
Email + Task (version2)
So it's not that the stamped item has 2 creation dates, so much as it 
has 1 creation date and 1 modified date.

>     * Does a stamped item always have one ACL, or can it have N?
One

>     * Is a stamped item always shared as a whole thing?
Yes

>     * Does a stamped item have one body or two?
One

>           o With an email stamped as a task, the email body could 
> become the body of the task-like stamped item. Or, the email body 
> could remain the email body, and have a separate task body.
The Email body becomes the Task body

>     * Can you ever delete one aspect of a stamped item? Or is this 
> "unstamping"?
You can delete version2 (E+T) and just retain the original Email 
(version1)

>     * Can you ever separate a stamped item into two items?
See above

>     * Does a stamped item have a single version history, or can you 
> follow separate version histories for each aspect?
A stamped item is version2 of the original item, so in that sense they 
are 2 versions in a single version history.

>     * Normally a task-stamped email shows up as a task. Does a search 
> hit on the email aspect of a task-stamped email show up as a task too?
So the user would search for all communications items. In that sense, 
if the task was "communicated", then it would show up as a 
communications item AND as a task. In the "bags of attributes" mental 
model, the stamped item has both "communications" attributes and "task" 
attributes.
>
> It's Ok if we'd like some of these to behave as if the stamped item 
> were one thing, and others to behave the other way -- let's figure out 
> what the user would like to happen first, then see if we can make it 
> happen without being too confusing :)
>
> Thanks,
> Lisa
>

-------------------------------
This was regarded as good news!  In every case, the model was one item, 
not multiple linked items.  This made it seem clear that the "morph" 
model was the way to go, and gave me and John the confidence to request 
the needed underlying support in the repository to be able to change an 
item's kind.

John and Katie and I met with Andi to talk about adding support for 
changing an item's Kind into the repository.  I wrote a wiki page to 
cover the discussion:
http://wiki.osafoundation.org/bin/view/Chandler/CPIAContentModelSupport
At the meeting we resolved some of the key implementation issues at the 
repository level: what do you do with attributes that conflict?  What 
do you do with attributes that go away? etc.  We quickly resolved those 
issues, and Andi quickly built an implementation at the Data Model 
level.  The difficult part for him was supporting the ability to change 
an item's kind, since that's the general case of what happens when you 
morph kinds.

Then I built the Content Model implementation of stamping on top of 
Andi's work.  My level turned out to be more complicated than I would 
have liked, due to the "extra bag of attributes" issue.  I'm hopeful 
that we'll be able to remove that requirement, or work around it, to 
simplify the implementation.

The morph model really feels right to me for many scenarios.  When my 
wife sends me mail asking me to go to the store, she's really sent me a 
task in email form.  When my sister sends me a photo, it's both a mail 
message and a photo, morphed together as a single unit.

I'll be interested to follow this discussion as it develops.

- Donn Denman