Issue 5852: Generic port connections (components-ftf)
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity: 
Summary: I propose to introduce generic operations that allow
interconnecting ports regardless of their type. This
would ease generic programming.


The first part of the proposal is to allow generic
usage of the "connect" and "disconnect" operations
that are (currently) in the Receptacles interface,
i.e. to extend the functionality to not only work
on receptacles, but also on event source ports
(emits and publishes keywords).


The names "connect" and "disconnect" are appropriate
for any kind of port, and their signatures are the
same as "subscribe" and "unsubscribe" in the Events
interface.


The second part of the proposal is to introduce a
new operation "get_port" into the CCMObject interface.
This operation would take a FeatureName parameter and
return the object reference associated with that
facet or event sink.


So I propose the following steps:


1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.


2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)


3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.


I believe that these changes would also be of interest
for slimming down CCM for the Lightweight CCM RFP, and
in light of the Streams for CCM RFP (which will likely
add another port type that needs interconnecting).


This change does not have any impact on component
implementations. The change to CCM implementations
(ORBs) is neglegible (I would expect a day to make
these changes in MicoCCM, another day to test them).


If there is general agreement on this issue, I will
draft the text updates.

Resolution: 
Revised Text: 
Actions taken:
February 6, 2003: received issue
Discussion: 

End of Annotations:=====
From: "Pilhofer, Frank" <fpilhofe@mc.com> 
To: "'issues@omg.org'" <issues@omg.org> 
Subject: Generic port connections 
Date: Thu, 6 Feb 2003 12:04:31 -0500 
X-Mailer: Internet Mail Service (5.5.2653.19) 



This is a new issue for the Components-RTF:


I propose to introduce generic operations that allow
interconnecting ports regardless of their type. This
would ease generic programming.


The first part of the proposal is to allow generic
usage of the "connect" and "disconnect" operations
that are (currently) in the Receptacles interface,
i.e. to extend the functionality to not only work
on receptacles, but also on event source ports
(emits and publishes keywords).


The names "connect" and "disconnect" are appropriate
for any kind of port, and their signatures are the
same as "subscribe" and "unsubscribe" in the Events
interface.


The second part of the proposal is to introduce a
new operation "get_port" into the CCMObject interface.
This operation would take a FeatureName parameter and
return the object reference associated with that
facet or event sink.


So I propose the following steps:


1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.


2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)


3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.


I believe that these changes would also be of interest
for slimming down CCM for the Lightweight CCM RFP, and
in light of the Streams for CCM RFP (which will likely
add another port type that needs interconnecting).


This change does not have any impact on component
implementations. The change to CCM implementations
(ORBs) is neglegible (I would expect a day to make
these changes in MicoCCM, another day to test them).


If there is general agreement on this issue, I will
draft the text updates.


Frank Pilhofer
Mercury Computer Systems, Inc