[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Misadventures exploring "@coupledTo" for proposed resolution of ASSEMBLY-227
As per my action item, I've been trying to write up the approach
that I agreed to, the one that Mike suggested: http://lists.oasis-open.org/archives/sca-assembly/201011/msg00100.html Mike labeled this as "@mustConnectTo" in his proposal, but I thought it more natural to call this "@coupledTo". Rather than spell out the changes I was making, let me instead describe the corner I found myself in. Just about the time I wrote this: "The coupled consumer and producer of a component is defined as a consumer and producer from a component, where the componentType of the component in question defines a consumer that has been @coupledTo a producer from the same component." ... I realized I was in trouble. To make this notion work, when talking about composites, we have to make normative statements to the effect of "whenever you promote a consumer coupled to a producer, or vice-versa, the "coupled" consumer or producer MUST also be promoted, and the resulting consumer and producer MUST be reflected into the componentType of the composite as being coupled." To that end, I wanted to define a notion of "coupled consumer and producer of a component." That way, I could say more simply: "Either both parts of a coupled consumer and producer of a component MUST be promoted and remain coupled, or neither is." We've also discussed that a "coupled consumer and producer of a component" must also both be connected to a channel, if either of them are. I can only begin to imagine the verbal knots we're going to get into when we start applying policies, and have to introduce gems like "the coupled consumer and producer of a component" must share the same policy intents and policy sets. The difficulty here stems from a simple problem - producers and consumers, so far at least, have independent existence, and now we want to add text that couples them together tightly while still giving them an independent identity. Having tried to write it up that way, I conclude it is far more natural to reflect the notion of "prosumer" (http://en.wiktionary.org/wiki/prosumer) (or conducer http://en.wiktionary.org/wiki/conduce?) as Anish has stated, because:
Having come to this conclusion, and considering that I want something ready for our next call, I'm going to take a run at writing up the "prosumer" approach starting Thursday or Friday of this week. That is, unless I hear from others enough that convinces me I'm jumping the gun. -Eric. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]