Hi Mimi,
> 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.
That's right.
> 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".
Well, sort of, tight coupling could be used to allow this. But I think
I failed to illuminate what the key is here.
With our 0.6 feature set, whether stamping uses tight coupling or
identity coupling is mostly an implementation detail the design team
would hopefully not even notice.
What you probably WOULD notice, though, is that moving forward engineers
would stop looking confused when something like
<http://lists.osafoundation.org/pipermail/design/2006-March/004356.html>
is mentioned. The problem here is that if the event and the book are
the same item, I just can't imagine a reasonable way to model the same
book "being" multiple events. That I can't imagine it may be a failure
of imagination, or an architecture failure.
There are definitely questions about how shared attributes should work
and other details if we moved towards tight coupling, so I'm not saying
the design team doesn't need to be involved, just that I want to get the
applications team out of this rut where we're locked into our current
implementation and can't get over the hump to the functionality the
design team is seeking.
> 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.
Yup.
> 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)
I didn't go into clusters because I didn't want to muddy the waters (I
actually deleted my paragraph about them in my draft :) ), certainly
clusters are connected to the way we model and render connected items.
I think I'm interesting in partitioning discussion about clusters and
threads separately from coupling/stamping because I see clusters as
mainly affecting rendering in the summary view, coupling/stamping mainly
affecting what's rendered in the detail view. But if we reengineer
stamping, we'll want to consider clustering, too.
Sincerely,
Jeffrey