[Design] Re: [Chandler-dev] Reengineering stamping

[Alec Flett]

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 
model them.

(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 
sense anymore.

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 
object.

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.

Alec