[Design] Re: [Chandler-dev] Reengineering stamping
john at osafoundation.org
Thu Mar 16 09:18:18 PST 2006
Ted Leung wrote:
> [ in an effort to reduce the number of cross posts, I'm just replying
> to chandler-dev, since this is more about the implementation than the
> design, at least in my mind ]
> Alec Flett wrote:
>> 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.
> There might be other ways to preserve item identity if that was what
> we wanted, such as Annotations. However, I think I agree that the
> kind morphing that we are doing now is problematic.
Can someone summarize the implementation headaches with stamping as now
>> In my mind, the crux of the matter is whether identity coupling is truly
>> necessary all the way down in the domain model.
> I think the answer to this question lies in whether we are a talking
> about stamping as a UI/display characteristic or not. For example,
> when we share, we use the item cloud notion to mark out a bunch of
> items that must be treated as a unit in order for sharing to work
> correctly. So if something is stamped in the end user/design sense,
> what do we expect it's sharing behavior to be? Another are where
> this might matter is searching. If you do a search/filtered
> collection do you expect to see the rest of the stamped items in the
> result of the search?
>> 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")
> If we can do that without problems for sharing or searching, then I'd
> agree with this.
>> 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")
> In the implementation we have 3 mechanisms, possibly 4, available for
> relating items.
> 1. attributes whose values are scalars
> 2. attributes whose values are other items
> 3. kind morphing
> 4. annotations
> I think it's pretty clear that there are problems with using #3 to
> implement the stamping design that Mimi is after. Since all problems
> in CS can be solved with indirection, I'm pretty sure there's a way to
> solve our problems using #2, but I have a feeling this might be more
> complicated than we think it will be. Since #4 works on a per class
> basis, it also feels like the wrong solution, since stamps aren't
> applied to all items of a kind/class.
>> [and yes, those are terrible names.. and that may not even be the
>> "right" way to implement it]
> Using a naming convention is certainly one way of implementing it.
> The usual problem with naming conventions is name clashes or
> misspelling of names.
> On the whole, I'm in agreement with a lot that Jeffrey and Alec said,
> but there are still some things that trouble me and I need some more
> time to ponder. I just wanted to add a few thoughts while I had them.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "chandler-dev" mailing list
More information about the chandler-dev