[Chandler-dev] Reengineering stamping
mimi at osafoundation.org
Wed Mar 15 14:20:06 PST 2006
Thank you for writing this up.
Let me try to re-phrase what you just wrote in design terms and see
if we're still on the same page:
I get 1(Identiy coupling) and 3 (Loose coupling), I see the point of
2, though I'm not sure we need to address this use case in the short-
term. But I think there's a missing relationship type: Threads.
1. Identity coupling as you said is a 1-1 coupling. So this to me
would be like: Putting an email on the Task list. Putting a Task on
the Calendar. What we call Stamping today.
2. Tight coupling is having more than 2 items in the same Kind branch
stamped with a 3rd (ie. 2 Spec proposals are the combined Agenda for
a Meeting, so you would want to put both on the calendar for the same
Meeting). So you might multi-select 2 Spec-items in the Summary table
view and Stamp them both to "Put on the calendar".
3. Loose coupling is simply having attributes on an item point to
another item. ie. Jeffrey in the To: field points to a Contacts item
for Jeffrey Harris.
4. The 4th kind of relationship I see is the thread relationship.
There are many variationson the thread relationship, but the basic
characteristic is Explicit order (that the user could potentially
tweak). Examples of thread relationships:
+ Discussion/Conversation threads
+ Task dependency threads
+ Event series / Recurrence threads
(This has roughly been our notion of Clusters)
On Mar 15, 2006, at 1:46 PM, Jeffrey Harris wrote:
> Towards the end of the stamping design meeting Tuesday, we had a
> discussion about engineering issues and stamping. What follows are my
> take aways from that conversation.
> Spectrum of linking
> There are three broad categories of linking that Chandler is likely to
> use, it's helpful to lay these out and look at what we're doing now.
> Identity coupling
> Identity coupling is what stamping currently does. If an email "A" is
> stamped as an event, that event and that email become the same thing,
> they share an identity, they're both "A".
> The way we currently model this is to have one item whose kind and
> correlate with the different notions we're combining.
> This isn't the only conceivable way to achieve this, a year ago PJE
> argued for modeling this using composition rather than multiple
> inheritance (see the thread starting at
> Regardless of how we model this, identity coupling forces a one to one
> relationship between different kinds (i.e., there's just one email
> a user see as "being" the event).
> This one to one relationship makes the concept of shared attributes
> between two or more disparate kinds at least comprehensible, if not
> necessarily easy to implement.
> Tight coupling
> Here I'm going out on a limb a bit, but I'm hoping using this
> terminology may make the stamping conversations more comprehensible
> to all.
> I see tight coupling as being a connection between two or more
> conceptual items (one conceptual item may in fact be modeled with
> several linked items) such that when the user displays email "A", they
> also see event "B", and vice versa, when viewing event "B", they see
> email "A".
> My sense is that in some cases, when Mimi talks about stamping, she
> wants users to experience tight coupling, but identity coupling isn't
> Currently, our only mechanism for providing tight coupling is
> which is implemented as identity coupling. My sense is that the
> ultimate Chandler vision will provide a variety of ways of create
> coupling, stamping is intended to be one, very low effort for the
> affordance for creating tight coupling.
> In summary, it's important when planning Chandler's architecture
> not to
> conflate identity coupling with tight coupling. It's also
> important not
> to see stamping as the only way to cause tight coupling to happen.
> Loose coupling
> Loose coupling is a link between two items which can be "drilled
> similar to an anchor tag on an HTML page. If an email "A" and an
> "B" are loosely coupled, when viewing "A", a clickable subset of "B"
> appears, and vice versa.
> It's reasonable to imagine a spectrum of coupling, ranging from
> displaying just the title of an item (loose coupling), to displaying a
> proper subset of the item (displaying a conversation thread in-line,
> without all associated meta-data, for instance), to displaying the
> item with the other item (tight coupling).
> In this context, from a user's perspective, stamping an item
> creates one
> tightly coupled item. Unstamping decouples and deletes one item.
> The place where identity coupling comes into play is handling shared
> attributes, like title or comment body. It's not clear to me that
> identity coupling is the only way to achieve what appears to the
> user as
> a shared attribute.
> There may be circumstances where identity coupling is crucial to
> as opposed to identity coupling, I'd be interested in hearing use
> for this.
> One to many relationships
> One area of confusion has been the set of use cases where the
> concept of
> stamping is connected to several items of the same kind. For
> suppose an event is stamped as communication (email, but perhaps IM in
> the future), sent, then edited to include an additional recipient and
> sent again.
> In this circumstance, there are clearly at least two emails in play in
> the universe. In the repository, is the first email replaced by the
> second email? Are there two versions which are navigable by the user?
> Do we save both but only render the latest email to the user?
> My understanding of the design goal is to model this as one event,
> associated history information and chatter. If stamping as
> communication is seen not as identity coupling the event with one
> but rather opening a slot on the event for many coupled (loosely?
> tightly? somewhere in between?) communications, and enabling
> affordances like send and update buttons, the situation becomes easier
> for me at least to wrap my brain around.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev