Issue 15904: Add several with_profile methods (data-distribution-rtf) Source: Remedy IT (Mr. Johnny Willemsen, jwillemsen(at)remedy.nl) Nature: Enhancement Severity: Minor Summary: DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile. local interface DomainParticipant : Entity { Publisher create_publisher_with_profile( in string library_name, in string profile_name, in PublisherListener a_listener, in StatusMask mask); Subscriber create_subscriber_with_profile( in string library_name, in string profile_name, in SubscriberListener a_listener, in StatusMask mask); Topic create_topic_with_profile( in string topic_name, in string type_name, in string library_name, in string profile_name, in TopicListener a_listener, in StatusMask mask); }; local interface DomainParticipantFactory { DomainParticipant create_participant_with_profile( in DomainId_t domain_id, in string library_name, in string profile_name, in DomainParticipantListener a_listener, in StatusMask mask); ReturnCode_t set_default_participant_qos_with_profile( in string library_name, in string profile_name); }; local interface Publisher : Entity { DataWriter create_datawriter_with_profile( in Topic a_topic, in string library_name, in string probile_name, in DataWriterListener a_listener, in StatusMask mask); }; local interface Subscriber : Entity { DataReader create_datareader_with_profile( in TopicDescription a_topic, in string library_name, in string profile_name, in DataReaderListener a_listener, in StatusMask mask); }; Resolution: Revised Text: Actions taken: December 21, 2010: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2010 07:31:51 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Johnny Willemsen Employer: Remedy IT mailFrom: jwillemsen@remedy.nl Terms_Agreement: Specification: DDS Section: 7.2.3 FormalNumber: 2007-01-01 Version: 1.2 Doc_Year: 2007 Doc_Month: January Doc_Day: 01 Page: 145 Title: Add several with_profile methods Nature: Enhancement Severity: Minor CODE: 3TMw8 B1: Report Issue Description: DDS4CCM adds support for qos xml files. There is no api in dds to create a dp/sub/pub/rd/wr with a qos given from the xml file. We propose to add the following methods to the DDS IDL to create dds entities with a qos xml profile. local interface DomainParticipant : Entity { Publisher create_publisher_with_profile( in string library_name, in string profile_name, in PublisherListener a_listener, in StatusMask mask); Subscriber create_subscriber_with_profile( in string library_name, in string profile_name, in SubscriberListener a_listener, in StatusMask mask); Topic create_topic_with_profile( in string topic_name, in string type_name, in string library_name, in string profile_name, in TopicListener a_listener, in StatusMask mask); }; local interface DomainParticipantFactory { DomainParticipant create_participant_with_profile( in DomainId_t domain_id, in string library_name, in string profile_name, in DomainParticipantListener a_listener, in StatusMask mask); ReturnCode_t set_default_participant_qos_with_profile( in string library_name, in string profile_name); }; local interface Publisher : Entity { DataWriter create_datawriter_with_profile( in Topic a_topic, in string library_name, in string probile_name, in DataWriterListener a_listener, in StatusMask mask); }; local interface Subscriber : Entity { DataReader create_datareader_with_profile( in TopicDescription a_topic, in string library_name, in string profile_name, in DataReaderListener a_listener, in StatusMask mask); }; X-Virus-Scanned: by XS4ALL Virus Scanner Date: Wed, 05 Jan 2011 10:41:16 +0100 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.16) Gecko/20101125 SUSE/3.0.11 Lightning/1.0b1 Thunderbird/3.0.11 To: Juergen Boldt CC: issues@omg.org, data-distribution-rtf@omg.org Subject: [Issue 15903] issue 15904 -- DDS RTF issue Hi all, After some discussion we propose to slightly change our propose changes, instead of library_name/profile_name, we propose to replace these with just one string, called qos_profile. This qos_profile is proposed to be a url, where we hope that also the dds vendors standardize the exact possibilities of this url string. Johnny On 01/04/2011 10:34 PM, Juergen Boldt wrote: > >> From: webmaster@omg.org >> Date: 21 Dec 2010 07:31:51 -0500 >> To: >> Subject: Issue/Bug Report >> >> ******************************************************************************* >> Name: Johnny Willemsen >> Employer: Remedy IT >> mailFrom: jwillemsen@remedy.nl >> Terms_Agreement: >> Specification: DDS >> Section: 7.2.3 >> FormalNumber: 2007-01-01 >> Version: 1.2 >> Doc_Year: 2007 >> Doc_Month: January >> Doc_Day: 01 >> Page: 145 >> Title: Add several with_profile methods >> Nature: Enhancement >> Severity: Minor >> CODE: 3TMw8 >> B1: Report Issue >> >> Description: >> >> DDS4CCM adds support for qos xml files. There is no api in dds to >> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >> propose to add the following methods to the DDS IDL to create dds >> entities with a qos xml profile. >> >> local interface DomainParticipant : Entity { >> Publisher create_publisher_with_profile( >> in string library_name, >> in string profile_name, >> in PublisherListener a_listener, >> in StatusMask mask); >> Subscriber create_subscriber_with_profile( >> in string library_name, >> in string profile_name, >> in SubscriberListener a_listener, >> in StatusMask mask); >> Topic create_topic_with_profile( >> in string topic_name, >> in string type_name, >> in string library_name, >> in string profile_name, >> in TopicListener a_listener, >> in StatusMask mask); >> }; >> >> local interface DomainParticipantFactory { >> DomainParticipant create_participant_with_profile( >> in DomainId_t domain_id, >> in string library_name, >> in string profile_name, >> in DomainParticipantListener a_listener, >> in StatusMask mask); >> ReturnCode_t set_default_participant_qos_with_profile( >> in string library_name, >> in string profile_name); >> }; >> >> local interface Publisher : Entity { >> DataWriter create_datawriter_with_profile( >> in Topic a_topic, >> in string library_name, >> in string probile_name, >> in DataWriterListener a_listener, >> in StatusMask mask); >> }; >> >> local interface Subscriber : Entity { >> DataReader create_datareader_with_profile( >> in TopicDescription a_topic, >> in string library_name, >> in string profile_name, >> in DataReaderListener a_listener, >> in StatusMask mask); >> }; Subject: RE: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Date: Wed, 5 Jan 2011 09:29:40 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Thread-Index: Acus6yBlsImFEULDTwexJp5V684h/QAABBeA From: "King, Perry E." To: Cc: , X-OriginalArrivalTime: 05 Jan 2011 15:29:42.0449 (UTC) FILETIME=[5FC9FA10:01CBACED] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p05FUFiX023966 Hi Johnny, I think making this a URL will make it harder to map to some DDS implementations (RTI's in particular). I submitted another issue (15888) for the DDS4CCM DDS connectors that is "somewhat related" and that I think should be taken into account to come up with a common solution that can be used for both issues. I think it is very useful to have more than one profile in the same QoS definition/file (the RTI implementation currently allows this). My issue (15888) basically suggested (for the qos_profile attribute on the DDS4CCM DDS connectors) that the qos_profile attribute refer to a particular profile within a QoS definition, and separately there can be an optional reference to a path (or URL) to get to the actual QoS definition (typically a file). This URL would be optional so that if not specified, the location is implementation dependent. It seems to me that this same scheme could be used for these create_XXX_with_profile calls. This way there is one common means to refer to a particular qos_profile. The alternative (if issue 15888 were to be adopted, and your update were also adopted) would be that qos_profile would have completely different meanings in those two contexts which would just create confusion. Thank you, Perry King -----Original Message----- From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] Sent: Wednesday, January 05, 2011 4:41 AM To: Juergen Boldt Cc: issues@omg.org; data-distribution-rtf@omg.org Subject: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Hi all, After some discussion we propose to slightly change our propose changes, instead of library_name/profile_name, we propose to replace these with just one string, called qos_profile. This qos_profile is proposed to be a url, where we hope that also the dds vendors standardize the exact possibilities of this url string. Johnny On 01/04/2011 10:34 PM, Juergen Boldt wrote: > >> From: webmaster@omg.org >> Date: 21 Dec 2010 07:31:51 -0500 >> To: >> Subject: Issue/Bug Report >> >> ************************************************************************ ******* >> Name: Johnny Willemsen >> Employer: Remedy IT >> mailFrom: jwillemsen@remedy.nl >> Terms_Agreement: >> Specification: DDS >> Section: 7.2.3 >> FormalNumber: 2007-01-01 >> Version: 1.2 >> Doc_Year: 2007 >> Doc_Month: January >> Doc_Day: 01 >> Page: 145 >> Title: Add several with_profile methods >> Nature: Enhancement >> Severity: Minor >> CODE: 3TMw8 >> B1: Report Issue >> >> Description: >> >> DDS4CCM adds support for qos xml files. There is no api in dds to >> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >> propose to add the following methods to the DDS IDL to create dds >> entities with a qos xml profile. >> >> local interface DomainParticipant : Entity { >> Publisher create_publisher_with_profile( >> in string library_name, >> in string profile_name, >> in PublisherListener a_listener, >> in StatusMask mask); >> Subscriber create_subscriber_with_profile( >> in string library_name, >> in string profile_name, >> in SubscriberListener a_listener, >> in StatusMask mask); >> Topic create_topic_with_profile( >> in string topic_name, >> in string type_name, >> in string library_name, >> in string profile_name, >> in TopicListener a_listener, >> in StatusMask mask); >> }; >> >> local interface DomainParticipantFactory { >> DomainParticipant create_participant_with_profile( >> in DomainId_t domain_id, >> in string library_name, >> in string profile_name, >> in DomainParticipantListener a_listener, >> in StatusMask mask); >> ReturnCode_t set_default_participant_qos_with_profile( >> in string library_name, >> in string profile_name); >> }; >> >> local interface Publisher : Entity { >> DataWriter create_datawriter_with_profile( >> in Topic a_topic, >> in string library_name, >> in string probile_name, >> in DataWriterListener a_listener, >> in StatusMask mask); >> }; >> >> local interface Subscriber : Entity { >> DataReader create_datareader_with_profile( >> in TopicDescription a_topic, >> in string library_name, >> in string profile_name, >> in DataReaderListener a_listener, >> in StatusMask mask); >> }; From: "Thier, John E." To: "jwillemsen@remedy.nl" , Juergen Boldt CC: "issues@omg.org" , "data-distribution-rtf@omg.org" Date: Wed, 5 Jan 2011 09:39:08 -0600 Subject: RE: [Issue 15903] issue 15904 -- DDS RTF issue Thread-Topic: [Issue 15903] issue 15904 -- DDS RTF issue Thread-Index: Acus6sDpQA8rkbOaSOiil3FE3ujGSAAAtsLA Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p05FdNFQ024864 I have a question regarding this change. Reading the dds4ccm, a profile is defined as an associated set of QoS values (i.e., those for an entity). I would expect all the QoS for a DDS instance to be included in one file (the 'library') with a single URL. An individual profile would be an XML block within that file, which would need some sort of separate string identifier. By going to a single URL string, it seems that we would be forcing each profile to be an individual XML file. John Thier General Dynamics Advanced Information Systems -----Original Message----- From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] Sent: Wednesday, January 05, 2011 4:41 AM To: Juergen Boldt Cc: issues@omg.org; data-distribution-rtf@omg.org Subject: [Issue 15903] issue 15904 -- DDS RTF issue Hi all, After some discussion we propose to slightly change our propose changes, instead of library_name/profile_name, we propose to replace these with just one string, called qos_profile. This qos_profile is proposed to be a url, where we hope that also the dds vendors standardize the exact possibilities of this url string. Johnny On 01/04/2011 10:34 PM, Juergen Boldt wrote: > >> From: webmaster@omg.org >> Date: 21 Dec 2010 07:31:51 -0500 >> To: >> Subject: Issue/Bug Report >> >> ******************************************************************************* >> Name: Johnny Willemsen >> Employer: Remedy IT >> mailFrom: jwillemsen@remedy.nl >> Terms_Agreement: >> Specification: DDS >> Section: 7.2.3 >> FormalNumber: 2007-01-01 >> Version: 1.2 >> Doc_Year: 2007 >> Doc_Month: January >> Doc_Day: 01 >> Page: 145 >> Title: Add several with_profile methods >> Nature: Enhancement >> Severity: Minor >> CODE: 3TMw8 >> B1: Report Issue >> >> Description: >> >> DDS4CCM adds support for qos xml files. There is no api in dds to >> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >> propose to add the following methods to the DDS IDL to create dds >> entities with a qos xml profile. >> >> local interface DomainParticipant : Entity { >> Publisher create_publisher_with_profile( >> in string library_name, >> in string profile_name, >> in PublisherListener a_listener, >> in StatusMask mask); >> Subscriber create_subscriber_with_profile( >> in string library_name, >> in string profile_name, >> in SubscriberListener a_listener, >> in StatusMask mask); >> Topic create_topic_with_profile( >> in string topic_name, >> in string type_name, >> in string library_name, >> in string profile_name, >> in TopicListener a_listener, >> in StatusMask mask); >> }; >> >> local interface DomainParticipantFactory { >> DomainParticipant create_participant_with_profile( >> in DomainId_t domain_id, >> in string library_name, >> in string profile_name, >> in DomainParticipantListener a_listener, >> in StatusMask mask); >> ReturnCode_t set_default_participant_qos_with_profile( >> in string library_name, >> in string profile_name); >> }; >> >> local interface Publisher : Entity { >> DataWriter create_datawriter_with_profile( >> in Topic a_topic, >> in string library_name, >> in string probile_name, >> in DataWriterListener a_listener, >> in StatusMask mask); >> }; >> >> local interface Subscriber : Entity { >> DataReader create_datareader_with_profile( >> in TopicDescription a_topic, >> in string library_name, >> in string profile_name, >> in DataReaderListener a_listener, >> in StatusMask mask); >> }; Subject: RE: EXTERNAL:RE: [Issue 15903] issue 15904 -- DDS RTF issue Date: Wed, 5 Jan 2011 11:59:21 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EXTERNAL:RE: [Issue 15903] issue 15904 -- DDS RTF issue Thread-Index: Acus6sDpQA8rkbOaSOiil3FE3ujGSAAAtsLAAATkFyA= From: "Hayman, Mark C." To: "Thier, John E." , , "Juergen Boldt" Cc: , X-OriginalArrivalTime: 05 Jan 2011 17:59:22.0705 (UTC) FILETIME=[48704C10:01CBAD02] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p05HxdhX008857 Hi John, Given that the qos_profile string could still be uniquely (and differently) defined for each DDS entity when using straight DDS, or in the case of component-based DDS using DDS4CCM - for each connector instance, this doesn't seem to be overly restrictive. Using DDS4CCM, you would be restricted to a single XML file only when defining the QoS settings for single connector instance, which in effect is for a single DDS topic and the associated DDS entities that are instantiated within the connector to access that topic. In a larger component-based DDS deployment with many different topics/connector instances, you could still potentially attach a qos_profile property to each one that references a different XML QoS file, and in effect distribute a single profile (for an overall deployment) across many different XML files. Mark Hayman Northrop Grumman Corp. -----Original Message----- From: Thier, John E. [mailto:John.Thier@gd-ais.com] Sent: Wednesday, January 05, 2011 10:39 AM To: jwillemsen@remedy.nl; Juergen Boldt Cc: issues@omg.org; data-distribution-rtf@omg.org Subject: EXTERNAL:RE: [Issue 15903] issue 15904 -- DDS RTF issue I have a question regarding this change. Reading the dds4ccm, a profile is defined as an associated set of QoS values (i.e., those for an entity). I would expect all the QoS for a DDS instance to be included in one file (the 'library') with a single URL. An individual profile would be an XML block within that file, which would need some sort of separate string identifier. By going to a single URL string, it seems that we would be forcing each profile to be an individual XML file. John Thier General Dynamics Advanced Information Systems -----Original Message----- From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] Sent: Wednesday, January 05, 2011 4:41 AM To: Juergen Boldt Cc: issues@omg.org; data-distribution-rtf@omg.org Subject: [Issue 15903] issue 15904 -- DDS RTF issue Hi all, After some discussion we propose to slightly change our propose changes, instead of library_name/profile_name, we propose to replace these with just one string, called qos_profile. This qos_profile is proposed to be a url, where we hope that also the dds vendors standardize the exact possibilities of this url string. Johnny On 01/04/2011 10:34 PM, Juergen Boldt wrote: > >> From: webmaster@omg.org >> Date: 21 Dec 2010 07:31:51 -0500 >> To: >> Subject: Issue/Bug Report >> >> ************************************************************************ ******* >> Name: Johnny Willemsen >> Employer: Remedy IT >> mailFrom: jwillemsen@remedy.nl >> Terms_Agreement: >> Specification: DDS >> Section: 7.2.3 >> FormalNumber: 2007-01-01 >> Version: 1.2 >> Doc_Year: 2007 >> Doc_Month: January >> Doc_Day: 01 >> Page: 145 >> Title: Add several with_profile methods >> Nature: Enhancement >> Severity: Minor >> CODE: 3TMw8 >> B1: Report Issue >> >> Description: >> >> DDS4CCM adds support for qos xml files. There is no api in dds to >> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >> propose to add the following methods to the DDS IDL to create dds >> entities with a qos xml profile. >> >> local interface DomainParticipant : Entity { >> Publisher create_publisher_with_profile( >> in string library_name, >> in string profile_name, >> in PublisherListener a_listener, >> in StatusMask mask); >> Subscriber create_subscriber_with_profile( >> in string library_name, >> in string profile_name, >> in SubscriberListener a_listener, >> in StatusMask mask); >> Topic create_topic_with_profile( >> in string topic_name, >> in string type_name, >> in string library_name, >> in string profile_name, >> in TopicListener a_listener, >> in StatusMask mask); >> }; >> >> local interface DomainParticipantFactory { >> DomainParticipant create_participant_with_profile( >> in DomainId_t domain_id, >> in string library_name, >> in string profile_name, >> in DomainParticipantListener a_listener, >> in StatusMask mask); >> ReturnCode_t set_default_participant_qos_with_profile( >> in string library_name, >> in string profile_name); >> }; >> >> local interface Publisher : Entity { >> DataWriter create_datawriter_with_profile( >> in Topic a_topic, >> in string library_name, >> in string probile_name, >> in DataWriterListener a_listener, >> in StatusMask mask); >> }; >> >> local interface Subscriber : Entity { >> DataReader create_datareader_with_profile( >> in TopicDescription a_topic, >> in string library_name, >> in string profile_name, >> in DataReaderListener a_listener, >> in StatusMask mask); >> }; X-Virus-Scanned: by XS4ALL Virus Scanner Date: Wed, 05 Jan 2011 19:18:52 +0100 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.16) Gecko/20101125 SUSE/3.0.11 Lightning/1.0b1 Thunderbird/3.0.11 To: "King, Perry E." CC: data-distribution-rtf@omg.org Subject: Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Hi, > I think making this a URL will make it harder to map to some DDS > implementations (RTI's in particular). I submitted another issue > (15888) for the DDS4CCM DDS connectors that is "somewhat related" and > that I think should be taken into account to come up with a common > solution that can be used for both issues. The ideal solution would be that the DDS vendors would agree on a common URL and also update their products to support such an URL like qos_profile string. > I think it is very useful to have more than one profile in the same QoS > definition/file (the RTI implementation currently allows this). You could do that with an url, something like file://myfile.xml/profile/library First the file, than profile, than library, just as a file path. > My issue (15888) basically suggested (for the qos_profile attribute on > the DDS4CCM DDS connectors) that the qos_profile attribute refer to a > particular profile within a QoS definition, and separately there can be > an optional reference to a path (or URL) to get to the actual QoS > definition (typically a file). This URL would be optional so that if > not specified, the location is implementation dependent. > > It seems to me that this same scheme could be used for these > create_XXX_with_profile calls. This way there is one common means to > refer to a particular qos_profile. The alternative (if issue 15888 were > to be adopted, and your update were also adopted) would be that > qos_profile would have completely different meanings in those two > contexts which would just create confusion. The definition of qos_profile should be in the DDS specification to my idea, DDS4CCM should just refer to that specification. Than we don't have todo much in dds4ccm, just remove some parts. Johnny > > Thank you, > > Perry King > > -----Original Message----- > From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] > Sent: Wednesday, January 05, 2011 4:41 AM > To: Juergen Boldt > Cc: issues@omg.org; data-distribution-rtf@omg.org > Subject: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue > > Hi all, > > After some discussion we propose to slightly change our propose changes, > instead of library_name/profile_name, we propose to replace these with > just one string, called qos_profile. This qos_profile is proposed to be > a url, where we hope that also the dds vendors standardize the exact > possibilities of this url string. > > Johnny > > On 01/04/2011 10:34 PM, Juergen Boldt wrote: >> >>> From: webmaster@omg.org >>> Date: 21 Dec 2010 07:31:51 -0500 >>> To: >>> Subject: Issue/Bug Report >>> >>> > ************************************************************************ > ******* >>> Name: Johnny Willemsen >>> Employer: Remedy IT >>> mailFrom: jwillemsen@remedy.nl >>> Terms_Agreement: >>> Specification: DDS >>> Section: 7.2.3 >>> FormalNumber: 2007-01-01 >>> Version: 1.2 >>> Doc_Year: 2007 >>> Doc_Month: January >>> Doc_Day: 01 >>> Page: 145 >>> Title: Add several with_profile methods >>> Nature: Enhancement >>> Severity: Minor >>> CODE: 3TMw8 >>> B1: Report Issue >>> >>> Description: >>> >>> DDS4CCM adds support for qos xml files. There is no api in dds to >>> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >>> propose to add the following methods to the DDS IDL to create dds >>> entities with a qos xml profile. >>> >>> local interface DomainParticipant : Entity { >>> Publisher create_publisher_with_profile( >>> in string library_name, >>> in string profile_name, >>> in PublisherListener a_listener, >>> in StatusMask mask); >>> Subscriber create_subscriber_with_profile( >>> in string library_name, >>> in string profile_name, >>> in SubscriberListener a_listener, >>> in StatusMask mask); >>> Topic create_topic_with_profile( >>> in string topic_name, >>> in string type_name, >>> in string library_name, >>> in string profile_name, >>> in TopicListener a_listener, >>> in StatusMask mask); >>> }; >>> >>> local interface DomainParticipantFactory { >>> DomainParticipant create_participant_with_profile( >>> in DomainId_t domain_id, >>> in string library_name, >>> in string profile_name, >>> in DomainParticipantListener a_listener, >>> in StatusMask mask); >>> ReturnCode_t set_default_participant_qos_with_profile( >>> in string library_name, >>> in string profile_name); >>> }; >>> >>> local interface Publisher : Entity { >>> DataWriter create_datawriter_with_profile( >>> in Topic a_topic, >>> in string library_name, >>> in string probile_name, >>> in DataWriterListener a_listener, >>> in StatusMask mask); >>> }; >>> >>> local interface Subscriber : Entity { >>> DataReader create_datareader_with_profile( >>> in TopicDescription a_topic, >>> in string library_name, >>> in string profile_name, >>> in DataReaderListener a_listener, >>> in StatusMask mask); >>> }; > Subject: RE: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Date: Wed, 5 Jan 2011 12:38:46 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Thread-Index: AcutBbFg23n5d772RICP0RjG9P7ZXwAAIkJg From: "King, Perry E." To: Cc: X-OriginalArrivalTime: 05 Jan 2011 18:38:50.0875 (UTC) FILETIME=[CBFA5CB0:01CBAD07] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p05Id6Bm013116 Hi Johnny, That sounds like a very reasonable compromise. I especially like the idea of the definition of the url only being defined in one place. I'm hoping that the DDS4CCM/CCM RTF is also going to move section "8.4.2 DDS QoS Policies in XML" from the DDS4CCM spec to the DDS spec. This would seem to make sense. Thanks, -- Perry King -----Original Message----- From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] Sent: Wednesday, January 05, 2011 1:19 PM To: King, Perry E. Cc: data-distribution-rtf@omg.org Subject: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Hi, > I think making this a URL will make it harder to map to some DDS > implementations (RTI's in particular). I submitted another issue > (15888) for the DDS4CCM DDS connectors that is "somewhat related" and > that I think should be taken into account to come up with a common > solution that can be used for both issues. The ideal solution would be that the DDS vendors would agree on a common URL and also update their products to support such an URL like qos_profile string. > I think it is very useful to have more than one profile in the same QoS > definition/file (the RTI implementation currently allows this). You could do that with an url, something like file://myfile.xml/profile/library First the file, than profile, than library, just as a file path. > My issue (15888) basically suggested (for the qos_profile attribute on > the DDS4CCM DDS connectors) that the qos_profile attribute refer to a > particular profile within a QoS definition, and separately there can be > an optional reference to a path (or URL) to get to the actual QoS > definition (typically a file). This URL would be optional so that if > not specified, the location is implementation dependent. > > It seems to me that this same scheme could be used for these > create_XXX_with_profile calls. This way there is one common means to > refer to a particular qos_profile. The alternative (if issue 15888 were > to be adopted, and your update were also adopted) would be that > qos_profile would have completely different meanings in those two > contexts which would just create confusion. The definition of qos_profile should be in the DDS specification to my idea, DDS4CCM should just refer to that specification. Than we don't have todo much in dds4ccm, just remove some parts. Johnny > > Thank you, > > Perry King > > -----Original Message----- > From: Johnny Willemsen [mailto:jwillemsen@remedy.nl] > Sent: Wednesday, January 05, 2011 4:41 AM > To: Juergen Boldt > Cc: issues@omg.org; data-distribution-rtf@omg.org > Subject: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue > > Hi all, > > After some discussion we propose to slightly change our propose changes, > instead of library_name/profile_name, we propose to replace these with > just one string, called qos_profile. This qos_profile is proposed to be > a url, where we hope that also the dds vendors standardize the exact > possibilities of this url string. > > Johnny > > On 01/04/2011 10:34 PM, Juergen Boldt wrote: >> >>> From: webmaster@omg.org >>> Date: 21 Dec 2010 07:31:51 -0500 >>> To: >>> Subject: Issue/Bug Report >>> >>> > ************************************************************************ > ******* >>> Name: Johnny Willemsen >>> Employer: Remedy IT >>> mailFrom: jwillemsen@remedy.nl >>> Terms_Agreement: >>> Specification: DDS >>> Section: 7.2.3 >>> FormalNumber: 2007-01-01 >>> Version: 1.2 >>> Doc_Year: 2007 >>> Doc_Month: January >>> Doc_Day: 01 >>> Page: 145 >>> Title: Add several with_profile methods >>> Nature: Enhancement >>> Severity: Minor >>> CODE: 3TMw8 >>> B1: Report Issue >>> >>> Description: >>> >>> DDS4CCM adds support for qos xml files. There is no api in dds to >>> create a dp/sub/pub/rd/wr with a qos given from the xml file. We >>> propose to add the following methods to the DDS IDL to create dds >>> entities with a qos xml profile. >>> >>> local interface DomainParticipant : Entity { >>> Publisher create_publisher_with_profile( >>> in string library_name, >>> in string profile_name, >>> in PublisherListener a_listener, >>> in StatusMask mask); >>> Subscriber create_subscriber_with_profile( >>> in string library_name, >>> in string profile_name, >>> in SubscriberListener a_listener, >>> in StatusMask mask); >>> Topic create_topic_with_profile( >>> in string topic_name, >>> in string type_name, >>> in string library_name, >>> in string profile_name, >>> in TopicListener a_listener, >>> in StatusMask mask); >>> }; >>> >>> local interface DomainParticipantFactory { >>> DomainParticipant create_participant_with_profile( >>> in DomainId_t domain_id, >>> in string library_name, >>> in string profile_name, >>> in DomainParticipantListener a_listener, >>> in StatusMask mask); >>> ReturnCode_t set_default_participant_qos_with_profile( >>> in string library_name, >>> in string profile_name); >>> }; >>> >>> local interface Publisher : Entity { >>> DataWriter create_datawriter_with_profile( >>> in Topic a_topic, >>> in string library_name, >>> in string probile_name, >>> in DataWriterListener a_listener, >>> in StatusMask mask); >>> }; >>> >>> local interface Subscriber : Entity { >>> DataReader create_datareader_with_profile( >>> in TopicDescription a_topic, >>> in string library_name, >>> in string profile_name, >>> in DataReaderListener a_listener, >>> in StatusMask mask); >>> }; > From: WATINE Virginie To: "King, Perry E." , "jwillemsen@remedy.nl" CC: "data-distribution-rtf@omg.org" Date: Thu, 6 Jan 2011 10:19:11 +0100 Subject: RE: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Thread-Topic: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue Thread-Index: AcutBbFg23n5d772RICP0RjG9P7ZXwAAIkJgAB7DQEA= Accept-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.0.0, Antivirus-Engine: 3.15.0, Antivirus-Data: 4.61E X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id p069JKrk014979 -----Message d'origine----- De : King, Perry E. [mailto:perry.king@ngc.com] Envoyé 05 January 2011 19:39 À: jwillemsen@remedy.nl Cc : data-distribution-rtf@omg.org Objet : RE: EXTERNAL:Re: EXTERNAL:[Issue 15903] issue 15904 -- DDS RTF issue [...] I'm hoping that the DDS4CCM/CCM RTF is also going to move section "8.4.2 DDS QoS Policies in XML" from the DDS4CCM spec to the DDS spec. This would seem to make sense. [vw] The purpose of the DDS4CCM/CCM RTF is to move one chapter of DDS4CCM to CCM. It is NOT chartered to to anything on the DDS specification. In case the second move you mentioned is to be done, it should be made either separately (but hopefully at the same time) in a DDS4CCM RTF and a DDS RTF or by a DDS4CCM/DDS joint RTF created for that purpose. And it should also take care of the compliance points. Kind regards, 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 ------------------------------------------