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

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

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.

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