Issue 15238: Let the user be able to instantiate one dds connector (dds4ccm-ftf) Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl) Nature: Clarification Severity: Minor Summary: Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State Resolution: Revised Text: Actions taken: May 3, 2010: received issue Discussion: No time to tackle it completely. Other solutions to minimize code generation are under investigation. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 03 May 2010 12:39:26 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Johnny Willemsen Company: Remedy IT mailFrom: jwillemsen@remedy.nl Notification: Yes Specification: DDS4CCM Section: 8.3 FormalNumber: 09-10-25 Version: 1.0 RevisionDate: Nov 2009 Page: 50 Title: Let the user be able to instantiate one dds connector Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Flag: NO X-Spam-Score: -0.066 X-Spam-Level: X-Spam-Status: No, score=-0.066 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.015, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_DATE_PAST_20XX=3.188] Date: Fri, 21 May 2010 15:57:24 +0200 From: Johnny Willemsen Reply-To: jwillemsen@remedy.nl Organization: Remedy IT User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-2.3 Lightning/1.0b1 Thunderbird/3.0.4 To: Virginie WATINE CC: dds4ccm Subject: Re: DDS4CCM - forgotten issue Hi, > Mark mentioned this remaining issue 15238 (that I missed) > << Currently the DDS4CCM specification puts within the Typed module > the extended ports, but also the dds connectors. The drawback of this > approach is that when the user instantiates this templated module he > gets both connectors, even when he is only interested in using one. We > propose to move the DDS_State and DDS_Event to their own typed module > so that the end user can instantiate just one of these connectors. > This also makes it easier for a code generator to just generate the > implementation for a specific connector, at this moment there is > nothing in idl which can be used to determine whether the end user > wants to use DDS_Event and/or DDS_State >> > > Actually when we designed the typed module, we considered that > possibility, but rejected it for the following reason: > Each typed module could to be considered as an isolation 'packet', > with as only entry points the template parameters. This means, that > except if we consider passing all the constructs related to extended > ports as template parameters in the connector typed module (meaning > relying on the developer to explicitly create the Ports module and > then pass all the constructs as template parameters in the > ConnectorModule -- which would be very cumbersome, ugly and really > error-prone), an interface used in an extended port and the same > provided by the mirror port cannot be same constructs , while they > have to be the same otherwise the connection is not feasible... I agree with this part > If we just import (alias) the Ports module in each of the Connector's > one, then all Ports' instanciations are duplicated, which we didn't > find desirable as well. When would it happen that someone would have one topic in IDL and needs both DDS_State and DDS_Event, wouldn't someone use just one connector type in 99.9% of the cases? If a large system needs both, it could be that one application uses DDS_Event, the other one DDS_State, for the full system this maybe leads to duplicated IDL, but only if they both instantiate the connector within the same namespace and compile it inside the same application, but probably than an implementation could disable one easily. My feeling is that we should go for the alias solution and do it now and not postpone it. Johnny > > > If you agree with that explanation, I propose to close with no change > that issue. > Otherwise, we will address it in the subsequent RTF. > > Please tell me as soon as you can, > > Cheers, > V. > > Date: Fri, 21 May 2010 16:13:49 +0200 From: Virginie WATINE User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) To: jwillemsen@remedy.nl CC: dds4ccm Subject: Re: DDS4CCM - forgotten issue I forgot to mention also that the "import" path leads to extra module names within the definitions, which complicates the reading/writing for the user developer. BTW, CARDAMOM's code generator allows to select what you need, so we are not facing the drawback you mention. Cheers, V. Johnny Willemsen a éit : Hi, Mark mentioned this remaining issue 15238 (that I missed) << Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State >> Actually when we designed the typed module, we considered that possibility, but rejected it for the following reason: Each typed module could to be considered as an isolation 'packet', with as only entry points the template parameters. This means, that except if we consider passing all the constructs related to extended ports as template parameters in the connector typed module (meaning relying on the developer to explicitly create the Ports module and then pass all the constructs as template parameters in the ConnectorModule -- which would be very cumbersome, ugly and really error-prone), an interface used in an extended port and the same provided by the mirror port cannot be same constructs , while they have to be the same otherwise the connection is not feasible... I agree with this part If we just import (alias) the Ports module in each of the Connector's one, then all Ports' instanciations are duplicated, which we didn't find desirable as well. When would it happen that someone would have one topic in IDL and needs both DDS_State and DDS_Event, wouldn't someone use just one connector type in 99.9% of the cases? If a large system needs both, it could be that one application uses DDS_Event, the other one DDS_State, for the full system this maybe leads to duplicated IDL, but only if they both instantiate the connector within the same namespace and compile it inside the same application, but probably than an implementation could disable one easily. My feeling is that we should go for the alias solution and do it now and not postpone it. Johnny If you agree with that explanation, I propose to close with no change that issue. Otherwise, we will address it in the subsequent RTF. Please tell me as soon as you can, Cheers, V. -- Virginie Watine Direction Technique Air Operations / Thales Air Systems (TR6) 3 avenue Charles Lindbergh BP 20351 - 94628 RUNGIS cedex - FRANCE Tel: + 33 1 79 61 20 62 Fax: + 33 1 79 61 58 20 mailto: virginie.watine@thalesgroup.com ------------------------------------------ X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.015, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_DATE_PAST_20XX=3.188, HTML_MESSAGE=0.001] Date: Fri, 21 May 2010 16:18:43 +0200 From: Johnny Willemsen Reply-To: jwillemsen@remedy.nl Organization: Remedy IT User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.0.4-2.3 Lightning/1.0b1 Thunderbird/3.0.4 To: Virginie WATINE CC: dds4ccm Subject: Re: DDS4CCM - forgotten issue Hi, On 05/21/2010 04:13 PM, Virginie WATINE wrote: I forgot to mention also that the "import" path leads to extra module names within the definitions, which complicates the reading/writing for the user developer. BTW, CARDAMOM's code generator allows to select what you need, so we are not facing the drawback you mention. You than added special pragma's or meta data to the IDL to select what you need? Johnny Cheers, V. Johnny Willemsen a éit : Hi, Mark mentioned this remaining issue 15238 (that I missed) << Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State >> Actually when we designed the typed module, we considered that possibility, but rejected it for the following reason: Each typed module could to be considered as an isolation 'packet', with as only entry points the template parameters. This means, that except if we consider passing all the constructs related to extended ports as template parameters in the connector typed module (meaning relying on the developer to explicitly create the Ports module and then pass all the constructs as template parameters in the ConnectorModule -- which would be very cumbersome, ugly and really error-prone), an interface used in an extended port and the same provided by the mirror port cannot be same constructs , while they have to be the same otherwise the connection is not feasible... I agree with this part If we just import (alias) the Ports module in each of the Connector's one, then all Ports' instanciations are duplicated, which we didn't find desirable as well. When would it happen that someone would have one topic in IDL and needs both DDS_State and DDS_Event, wouldn't someone use just one connector type in 99.9% of the cases? If a large system needs both, it could be that one application uses DDS_Event, the other one DDS_State, for the full system this maybe leads to duplicated IDL, but only if they both instantiate the connector within the same namespace and compile it inside the same application, but probably than an implementation could disable one easily. My feeling is that we should go for the alias solution and do it now and not postpone it. Johnny If you agree with that explanation, I propose to close with no change that issue. Otherwise, we will address it in the subsequent RTF. Please tell me as soon as you can, Cheers, V. -- Virginie Watine Direction Technique Air Operations / Thales Air Systems (TR6) 3 avenue Charles Lindbergh BP 20351 - 94628 RUNGIS cedex - FRANCE Tel: + 33 1 79 61 20 62 Fax: + 33 1 79 61 58 20 mailto: virginie.watine@thalesgroup.com ------------------------------------------