[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Misadventures exploring "@coupledTo" for proposedresolution of ASSEMBLY-227
One comment below. -Anish -- On 12/7/2010 10:58 AM, Eric Johnson wrote: > Hi Anish, > > Comment below: > > On 12/6/10 10:33 PM, Anish Karmarkar wrote: >> 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. > > Trouble is that the "groupID" notion adds an additional axis for > grouping, orthogonal to the existing promotion path, so in that sense, I > think it adds a great deal more complexity. Don't you think it would be > confusing if two consumers defined for a composite, and yet assigned the > same groupID? Why define them separately? Why not just promote the > underlying connections to the same consumer? The idea solves the > problem, but at the cost of extra complexity that isn't needed by the > use case. > Yes, indeed this provides additional flexibility. One reason I think one might do that (two consumers in a composite with same group ID) is because they have different intents. Now, we have an open issue wrt intents in eventing and if we resolve it to say that consumer/producer/channel intents much match then this, of course, serves no purpose. But this can easily be mitigated by saying that group names must be unique within the scope of all composite producers (and consumers), in the same sense that prosumer names would be unique. I still think that from a model perspective the two proposals are substantially similar ... and which is why I don't have a strong preference. I'll sketch out a few example tonight, to see how they look like in XML. -Anish -- > -Eric. >> >> -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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]