Re: [sca-assembly] Misadventures exploring "@coupledTo" for proposedresolution of ASSEMBLY-227

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

On 12/6/2010 4:05 PM, Eric Johnson wrote:
> Hi Anish,
>
> On 12/6/10 3:57 PM, Anish Karmarkar wrote:
>> I think this is fine.
>> Although, I do find the minimal change to CTs via Mike's proposal
>> attractive. But certainly understand the complications that come with
>> it wrt policy/intent and constrains like everything has to be promoted
>> or connected.
>>
>> A minor difference, perhaps inconsequential at this stage is, wrt how
>> I envisioned Mike's proposal to work:
>> I didn't think of a @mustConnectTo or @coupledTo as the attribute we
>> would use but an attribute such as @label or @groupID, which would be
>> any arbitrary string. The @mustConnectTo or @coupledTo identified
>> other consumers (or producers). I would rather the producers not point
>> to consumers (or vice versa). Instead, the producers and consumers
>> that are to be connected together would be identified with a common
>> label/group id.
>
> In one of the later emails, Mike and I discussed the problems with a
> generic label, and I think we both agreed that a "groupID" kind of
> notion allowed for an extra axis of flexibility (promoting to two
> consumers on the composite, for example, but assigning the same group
> ID) that isn't required by the use case, and simply introduces an extra
> opportunity for confusion and mis-wiring. So we had agreed on
> @mustConnectTo in the email referenced below (00100).
>

Isn't this problem/feature something that we already have? I don't think 
we need any additional protection for the user/assembler in this case.
One can connect the same underlying consumer (or producer) to the same 
channel multiple times in a variety of ways. If they do then they end up 
getting (or sending) the same message multiple times.

-Anish
--

> -Eric.
>
>>
>> -Anish
>> --
>>
>>
>> On 11/30/2010 1:47 PM, Eric Johnson wrote:
>>> 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:
>>>
>>> * That creates a thing with a single identity, to which specific
>>> rules can be applied
>>> * You don't have to create normative rules about how coupled
>>> consumers and producers must be both promoted or neither is
>>> promoted, and likewise about how they're both wired to a channel
>>> or not. With a single prosumer, there's no question of a split, so
>>> fewer normative constraints are required.
>>> * The policy questions, as applied to a prosumer, are likely
>>> different than those applied to consumers and producers independently
>>>
>>> The beauty of the "coupledTo" approach is that it leaves the
>>> componentType almost untouched - with just a single additional attribute
>>> on either the consumer or producer. Unfortunately, I think adds huge
>>> conceptual cost, and based on what I've seen from what I've tried to
>>> write up, it obscures the underlying intended model.
>>>
>>> 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.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php