[Chandler-dev] Reengineering stamping
alecf at osafoundation.org
Wed Mar 15 15:28:21 PST 2006
Mimi Yin wrote:
> Hi Jeffrey,
> 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 think part of the issue is that there are key differences between the
design and implementation of these relationships - from my perspective,
what jeffrey described is the domain model relationships and how they
might affect the implementation of the UI, and what you've described is
more about the design relationships and how you would design the UI to
(and I think threads are orthogonal to the implementation details that
Jeffrey is trying to work out)
> 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.
At the moment, we've tightly matched the design relationships (i.e.
"stamping") all the way down through the domain model (i.e. so
"stamping" == "identity") and I think that is why there has been so much
resistance to stamping from those implementing it. The implementation of
stamping-as-kind-morphing has caused us some serious headaches and the
0.7+ plans are looking even worse as long as we continue with our
current implementation. I'm sure it made sense at the time, but I think
the design of the product has become more concrete and it doesn't make
In my mind, the crux of the matter is whether identity coupling is truly
necessary all the way down in the domain model.
> 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.
I think Jeffrey is using "identity" in the mathematical sense - that it
isn't just a 1:1 mapping, but that the two objects are actually the same
For instance, my work self and my home self are really the same "Alec"
I think its interesting that you interpreted this as meaning putting an
object of one type on the list of another type, because I see that as
being orthogonal to the notion of identity, though I think it is an
important aspect of the design and appearance to the user. For instance,
if my wife comes to my work to watch a toad movie, this doesn't imply
that she IS me, but we are clearly tightly linked...
If the intent of the design is to make it look like, for example, a
calendar event is on my task list, there are other ways to implement
that beyond the identity mapping that we currently do.
I think frankly, it would behoove us to separate out the design notion
of an "Item" from the implementation notion of an "Item" because when
you (Mimi) say "An Item should have these properties and behave this
way" we're trying to match that too exactly in the domain model. (though
there is some irony that many people correctly point out that a "design
Item" is usually composed of many "implementation Items")
> 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".
No, tight coupling just describes the relationship between two "items"
- it by no means describes the number of items involved. Being tightly
coupled to my wife does not imply that there are three of us. :)
However even if we share a bank account, and mail from our bank comes
addressed to both of us at one physical address, the bank still has
separate internal records for each of us with our respective social
security numbers and credit history. When I call to look at our account
and give my identity information, the representative probably sees our
account, with both of our identity information on the screen at once.
> 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.
In the design sense, this is absolutely true. In the implementation,
there is little or no distinction between Tight and Loose coupling
besides perhaps the name of an attribute (for instance, tightly coupled
items may simply be related because their "tightlyCoupled" attributes
point to one another and loosely coupled items use "looselyCoupled")
[and yes, those are terrible names.. and that may not even be the
"right" way to implement it]
If my friend gave me a gift subscription to a magazine he also
subscribes to, then the publisher probably knows that we are somehow
connected and will probably remind my friend next year to renew his gift
subscription.. but we are by all intents and purposes separate customers.
I guess I could debate semantics forever and come up with more
analogies, but ultimately I think we need to loosen the tie between the
user's mental model and our domain model - they are not the same thing,
and by tying them too tightly together we're limiting the scope of what
chandler can really do.
More information about the chandler-dev