Re: [sca-assembly] attempt at thread summary: looking for feedbackon "injecting of channels"

Trying to pull the threads together on this discussion.  I'm going
    to run with the point I made in one of my emails - just what,
    exactly, are we exposing in the componentType when attempting to
    resolve 227?

    

    Three proposed approaches, and their effect:

    

    Eric: "Injected" channels, wherein componentType exposes a new
    element for the injectedChannel.  This effectively exposes the
    filters, events, policies of the consumers and producers connected
    to the "injected" channel.

    

    Mike: Continue to promote the consumers and producers, and then tie
    them together with a notion of "groupID".  In effect, this exposes
    the filters, events, policies of the consumers and producers and
    groups them for channel wiring purposes.

    

    Anish: "Prosumer" which promotes the a combination of consumers and
    producers.

    

    Writ-large, I think all of the above are introducing the exact same
    set of information into the componentType, with subtle variations in
    intended meaning.

    

    Mike's proposal compares to mine in that where I would not promote
    the consumers/producers tied to the injected channel, but then
    indicate some of the key metadata about the consumers/producers
    wired to the channel-to-be-injected, Mike's proposal would promote
    them, and then tie them together with groupID.  Key differences
    here:

    
      
Producers and consumers that could otherwise be "hidden" in
        the injected channel approach are now also available for
        independent wiring

      

      
No new element introduced into componentType

      
No implication of anything actually being wired - although
        when it is, there's a guarantee of being wired to the same thing

    
    

    Anish's proposal differs from mine in terminology, and in intent. 
    Where I would have the injected channel *always* provided, Anish's
    proposal would defer the wiring question to the composer of the
    containing composite.  Unclear to me - at least from Anish's latest
    email [1], is whether or not he sees the same information being in
    the componentType that apparently Mike and I do.  That is, Anish's
    email documents the change to the composite, not how it reflects in
    the componentType.  It is unclear from Anish's proposal (at least to
    me) whether or not the promoted producers & consumers are
    available for separate wiring.

    

    There's also a different pattern reflected in Anish and Mike's
    proposals - where the "injected channels" approach defines a 1-to-M
    mapping between a channel defined by a surrounding composite, and
    the producers/consumers wired to it, the proposals from Mike and
    Anish instead define a M-to-N relationship between the channels of
    the surrounding composite, and the producers/consumers of the
    contained component.

    

    Steps forward:

    1) Anish, can you provide a description of what you think ends up in
    the componentType in your prosumer model?

    

    2) If we pursue an approach like Anish and Mike's does anyone have
    any feedback on a policy intent notion like "must-wire", so that an
    inner composite can force that its consumers/producers are wired
    up?  This approach would then be a functional superset of my
    injected channels approach.

    

    Did I miss any differences?

    

    -Eric.

    

    [1]
    http://lists.oasis-open.org/archives/sca-assembly/201011/msg00038.html