Issue 15965: XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) (dds-psm-cxx-ftf) Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com) Nature: Uncategorized Issue Severity: Summary: The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API. The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form). A sketch of the suggested change is provided below: PolicyBuilder builder = PolicyBuilder::load("XMLBuilder"); TopicQos tqos = builder.topic_qos(file_name, profile_name); ============================================================================== Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches. Resolution: Revised Text: Actions taken: January 17, 2011: received issue Discussion: End of Annotations:===== te: Mon, 17 Jan 2011 12:12:37 +0100 From: Angelo Corsaro User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 To: DDS-PSM-Java FTF , DDS-PSM-Cxx FTF , Richard Warren , Juergen Boldt Subject: ISSUE: XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) Dear All, Below the description of an issue that applies to both the DDS-PSM-Cxx and the DDS-PSM-Java. ============================================================================== ISSUE The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API. The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form). A sketch of the suggested change is provided below: PolicyBuilder builder = PolicyBuilder::load("XMLBuilder"); TopicQos tqos = builder.topic_qos(file_name, profile_name); ============================================================================== Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 --------------------------------------------------------------------------------------------------------------------------------------- http://twitter.com/acorsaro | http://opensplice.blogspot.com | http://slideshare.net/angelo.corsaro --------------------------------------------------------------------------------------------------------------------------------------- x-cr-hashedpuzzle: JQbM M0HR Vt9g Y12b Zghv bpFu frdd r87J sLkK 3LRm +mD1 /J0N AAzOiQ== ABlm9w== ABvJVQ== ACLEyA==;6;ZABkAHMALQBwAHMAbQAtAGMAeAB4AC0AZgB0AGYAQABvAG0AZwAuAG8AcgBnADsAZABkAHMALQBwAHMAbQAtAGoAYQB2AGEALQBmAHQAZgBAAG8AbQBnAC4AbwByAGcAOwBpAHMAcwB1AGUAcwBAAG8AbQBnAC4AbwByAGcAOwBqAHUAZQByAGcAZQBuAEAAbwBtAGcALgBvAHIAZwA7AGoAdwBpAGwAbABlAG0AcwBlAG4AQAByAGUAbQBlAGQAeQAuAG4AbAA7AHIAdwBhAHIAcgBlAG4AQAByAHQAaQAuAGMAbwBtAA==;Sosha1_v1;7;{B35A73B7-0DEF-4120-B086-9F1191B53A9C};cABlAHIAcgB5AC4AawBpAG4AZwBAAG4AZwBjAC4AYwBvAG0A;Wed, 19 Jan 2011 20:20:11 GMT;UgBFADoAaQBzAHMAdQBlACAAMQA1ADkANgA1ACAALQAtACAASQBTAE8ALwBJAEUAQwAgAEMAKwArACAARABEAFMAIABQAFMATQAgAEYAVABGACAAaQBzAHMAdQBlAA== x-cr-puzzleid: {B35A73B7-0DEF-4120-B086-9F1191B53A9C} Subject: RE:issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Date: Wed, 19 Jan 2011 14:20:11 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Thread-Index: Acu3WmiH73w9T+4BTsKTa6bhEDZYtwAqOC4g From: "King, Perry E." To: "Juergen Boldt" , , Cc: "Richard Warren" , , X-OriginalArrivalTime: 19 Jan 2011 20:20:23.0535 (UTC) FILETIME=[4D44FFF0:01CBB816] Hi All, Conceptually I think Angelo.s idea is a good one. However (and I may be interpreting this wrong), I think he is suggesting that no changes be made to the spec, and instead that this PolicyBuilder is something that is either created by each user, or is provided by individual vendors, but in either case is not part of the standard. If true, I think that would be a mistake. As a user, I don.t want to write code to an API that is vendor specific. I also don.t want to .reinvent the wheel. and .roll my own.. I think it would make sense to standardize the public methods that this PolicyBuilder interface supports in order to extract out the QoS settings for all the DDS entities. This would allow user code that is given a PolicyBuilder pointer (assuming that PolicyBuilder is an abstract base class or interface) to work the same regardless of which DDS vendor it is using. Furthermore, I think it would also be useful to have defined in the spec, a factory class of some sorts that could be given at a minimum: 1. A URL to an XML file containing QoS settings 2. A string containing QoS settings 3. Nothing (would use .defaults. . actual values of the defaults would be vendor specific) The factory would produce an object built from one of the input types above that implements the PolicyBuilder interface. Since the factory would be separate from the PolicyBuilder a call like Angelo showed would not have the filename in it (since that would be specific to #1 above), but still would have a profile name. i.e., TopicQos tqos = builder.topic_qos(profile_name); Also, I think if PolicyBuilder were the actual name, it would be clearer to add an extra 3 letters and name it something like: QosPolicyBuilder Those are my thoughts as an end user rather than a DDS vendor. Thank you, Perry King From: Juergen Boldt [mailto:juergen@omg.org] Sent: Tuesday, January 18, 2011 4:55 PM To: issues@omg.org; dds-psm-cxx-ftf@omg.org Subject: EXTERNAL:issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Date: Mon, 17 Jan 2011 12:12:37 +0100 From: Angelo Corsaro User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 To: DDS-PSM-Java FTF , DDS-PSM-Cxx FTF , Richard Warren , Juergen Boldt Subject: ISSUE: XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) Dear All, Below the description of an issue that applies to both the DDS-PSM-Cxx and the DDS-PSM-Java. ============================================================================== ISSUE The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API. The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form). A sketch of the suggested change is provided below: PolicyBuilder builder = PolicyBuilder::load("XMLBuilder"); TopicQos tqos = builder.topic_qos(file_name, profile_name); ============================================================================== Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 --------------------------------------------------------------------------------------------------------------------------------------- http://twitter.com/acorsaro | http://opensplice.blogspot.com | http://slideshare.net/angelo.corsaro --------------------------------------------------------------------------------------------------------------------------------------- Date: Wed, 19 Jan 2011 23:34:16 +0100 From: Angelo Corsaro Organization: PrismTech User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 To: "King, Perry E." CC: Juergen Boldt , issues@omg.org, dds-psm-cxx-ftf@omg.org, Richard Warren , jwillemsen@remedy.nl, dds-psm-java-ftf@omg.org Subject: Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Hello Perry, On 19.1.11 9:20 PM, King, Perry E. wrote: Hi All, Conceptually I think Angelo.s idea is a good one. However (and I may be interpreting this wrong), I think he is suggesting that no changes be made to the spec, and instead that this PolicyBuilder is something that is either created by each user, or is provided by individual vendors, but in either case is not part of the standard. Perry, my suggestion was definitively to standardize the builder. Portability across DDS implementations is one of the issues that the new C++ API was trying to address and that is constantly on my mind If true, I think that would be a mistake. As a user, I don.t want to write code to an API that is vendor specific. I also don.t want to .reinvent the wheel. and .roll my own.. I think it would make sense to standardize the public methods that this PolicyBuilder interface supports in order to extract out the QoS settings for all the DDS entities. This would allow user code that is given a PolicyBuilder pointer (assuming that PolicyBuilder is an abstract base class or interface) to work the same regardless of which DDS vendor it is using. Furthermore, I think it would also be useful to have defined in the spec, a factory class of some sorts that could be given at a minimum: 1. A URL to an XML file containing QoS settings 2. A string containing QoS settings 3. Nothing (would use .defaults. . actual values of the defaults would be vendor specific) The factory would produce an object built from one of the input types above that implements the PolicyBuilder interface. Since the factory would be separate from the PolicyBuilder a call like Angelo showed would not have the filename in it (since that would be specific to #1 above), but still would have a profile name. i.e., TopicQos tqos = builder.topic_qos(profile_name); Also, I think if PolicyBuilder were the actual name, it would be clearer to add an extra 3 letters and name it something like: QosPolicyBuilder Those are my thoughts as an end user rather than a DDS vendor. Thanks for sharing your thoughts. I agree with your comments above, with the exception that I'd prefer a URI to an XML so that we can have remote and local resources. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 | twitter.com/acorsaro | slideshare.net/angelo.corsaro | Subject: RE: EXTERNAL:Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Date: Wed, 19 Jan 2011 17:00:41 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EXTERNAL:Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Thread-Index: Acu4KXPExBpyn8oXShW+zYRqIG922gAAqZPQ From: "King, Perry (ES)" To: "Angelo Corsaro" Cc: "Juergen Boldt" , , , "Richard Warren" , , X-OriginalArrivalTime: 19 Jan 2011 23:00:39.0856 (UTC) FILETIME=[B10B2300:01CBB82C] Hi Angelo, Great! I.m happy to hear that you will be attempting to standardize it. . and I agree with your comment about using a URI instead. Thanks, Perry From: Angelo Corsaro [mailto:angelo.corsaro@prismtech.com] Sent: Wednesday, January 19, 2011 5:34 PM To: King, Perry (ES) Cc: Juergen Boldt; issues@omg.org; dds-psm-cxx-ftf@omg.org; Richard Warren; jwillemsen@remedy.nl; dds-psm-java-ftf@omg.org Subject: EXTERNAL:Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Hello Perry, On 19.1.11 9:20 PM, King, Perry E. wrote: Hi All, Conceptually I think Angelo.s idea is a good one. However (and I may be interpreting this wrong), I think he is suggesting that no changes be made to the spec, and instead that this PolicyBuilder is something that is either created by each user, or is provided by individual vendors, but in either case is not part of the standard. Perry, my suggestion was definitively to standardize the builder. Portability across DDS implementations is one of the issues that the new C++ API was trying to address and that is constantly on my mind If true, I think that would be a mistake. As a user, I don.t want to write code to an API that is vendor specific. I also don.t want to .reinvent the wheel. and .roll my own.. I think it would make sense to standardize the public methods that this PolicyBuilder interface supports in order to extract out the QoS settings for all the DDS entities. This would allow user code that is given a PolicyBuilder pointer (assuming that PolicyBuilder is an abstract base class or interface) to work the same regardless of which DDS vendor it is using. Furthermore, I think it would also be useful to have defined in the spec, a factory class of some sorts that could be given at a minimum: A URL to an XML file containing QoS settings A string containing QoS settings Nothing (would use .defaults. . actual values of the defaults would be vendor specific) The factory would produce an object built from one of the input types above that implements the PolicyBuilder interface. Since the factory would be separate from the PolicyBuilder a call like Angelo showed would not have the filename in it (since that would be specific to #1 above), but still would have a profile name. i.e., TopicQos tqos = builder.topic_qos(profile_name); Also, I think if PolicyBuilder were the actual name, it would be clearer to add an extra 3 letters and name it something like: QosPolicyBuilder Those are my thoughts as an end user rather than a DDS vendor. Thanks for sharing your thoughts. I agree with your comments above, with the exception that I'd prefer a URI to an XML so that we can have remote and local resources. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 | twitter.com/acorsaro | slideshare.net/angelo.corsaro | X-Virus-Scanned: by XS4ALL Virus Scanner Date: Thu, 20 Jan 2011 11:08:53 +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: Angelo Corsaro CC: "King, Perry E." , Juergen Boldt , issues@omg.org, dds-psm-cxx-ftf@omg.org, Richard Warren , dds-psm-java-ftf@omg.org Subject: Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Hi all, > Thanks for sharing your thoughts. I agree with your comments above, with > the exception that I'd prefer a URI to an XML so that we can have remote > and local resources. We raised a regular DDS issue for using the XML QoS profile, issue 15904. This solution for the new C++/Java PSM are nice, but we also would like to see a general solution in DDS which is usable for anyone that is using the IDL version of the DDS API without the new PSMs. Johnny http://www.omg.org/issues/data-distribution-rtf.open.html#Issue15904 X-Virus-Scanned: by XS4ALL Virus Scanner Date: Thu, 20 Jan 2011 11:08:53 +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: Angelo Corsaro CC: "King, Perry E." , Juergen Boldt , issues@omg.org, dds-psm-cxx-ftf@omg.org, Richard Warren , dds-psm-java-ftf@omg.org Subject: Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Hi all, > Thanks for sharing your thoughts. I agree with your comments above, with > the exception that I'd prefer a URI to an XML so that we can have remote > and local resources. We raised a regular DDS issue for using the XML QoS profile, issue 15904. This solution for the new C++/Java PSM are nice, but we also would like to see a general solution in DDS which is usable for anyone that is using the IDL version of the DDS API without the new PSMs. Johnny http://www.omg.org/issues/data-distribution-rtf.open.html#Issue15904 Date: Thu, 20 Jan 2011 11:23:48 +0100 From: Angelo Corsaro Organization: PrismTech User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 To: jwillemsen@remedy.nl CC: "King, Perry E." , Juergen Boldt , issues@omg.org, dds-psm-cxx-ftf@omg.org, Richard Warren , dds-psm-java-ftf@omg.org Subject: Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Hello Johnny, On 20.1.11 11:08 AM, Johnny Willemsen wrote: Hi all, Thanks for sharing your thoughts. I agree with your comments above, with the exception that I'd prefer a URI to an XML so that we can have remote and local resources. We raised a regular DDS issue for using the XML QoS profile, issue 15904. This solution for the new C++/Java PSM are nice, but we also would like to see a general solution in DDS which is usable for anyone that is using the IDL version of the DDS API without the new PSMs. If we all agree that the builder is the good solution, than it should not be hard to introduce the same solution for the IDL PSM. Cheers, Angelo -- Angelo Corsaro, PhD Chief Technology Officer PrismTech 4 rue Angiboust | 91460 Marcoussis | France T +33 1 69 01 53 54 | M +33 6 42 30 75 65 | twitter.com/acorsaro | slideshare.net/angelo.corsaro | From: Richard Warren To: "King, Perry E." , Angelo Corsaro CC: "dds-psm-cxx-ftf@omg.org" , Johnny Willemsen , "dds-psm-java-ftf@omg.org" Date: Thu, 20 Jan 2011 11:37:32 -0800 Subject: Re: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Thread-Topic: issue 15965 -- ISO/IEC C++ DDS PSM FTF issue Thread-Index: Acu42XuchTIs/1ktTCW1Q+gIa9FyaA== 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 p0KJbaJs026534 Hi, I like the concept and I like Perry's name: QosPolicyBuilder. I think we do need to differentiate between the information that application programmers will need to provide (e.g. the profile name) and the information that system designers/administrators will need to provide (e.g. the path(s) where profiles can be found). The former should be in the API of the builder itself. The latter should be somewhere else -- maybe a policy on the participant factory? Regards, - Rick -- Rick Warren Principal Engineer RTI Tel 408.990.7455 rick.warren@rti.com www.rti.com RTI - The Global Leader in DDS On Jan 19, 2011, at 12:20 PM, King, Perry E. wrote: > Hi All, > Conceptually I think Angelo.s idea is a good one. However (and I may be interpreting this wrong), I think he is suggesting that no changes be made to the spec, and instead that this PolicyBuilder is something that is either created by each user, or is provided by individual vendors, but in either case is not part of the standard. > > If true, I think that would be a mistake. As a user, I don.t want to write code to an API that is vendor specific. I also don.t want to .reinvent the wheel. and .roll my own.. > > I think it would make sense to standardize the public methods that this PolicyBuilder interface supports in order to extract out the QoS settings for all the DDS entities. This would allow user code that is given aPolicyBuilder pointer (assuming that PolicyBuilder is an abstract base class or interface) to work the same regardless of which DDS vendor it is using. > > Furthermore, I think it would also be useful to have defined in the spec, a factory class of some sorts that could be given at a minimum: > 1. A URL to an XML file containing QoS settings > 2. A string containing QoS settings > 3. Nothing (would use .defaults. . actual values of the defaults would be vendor specific) > > The factory would produce an object built from one of the input types above that implements thePolicyBuilder interface. Since the factory would be separate from the PolicyBuilder a call like Angelo showed would not have the filename in it (since that would be specific to #1 above), but still would have a profile name. i.e., > > TopicQos tqos = builder.topic_qos(profile_name); > > Also, I think if PolicyBuilder were the actual name, it would be clearer to add an extra 3 letters and name it something like: QosPolicyBuilder > > Those are my thoughts as an end user rather than a DDS vendor. > > Thank you, > > Perry King > > From: Juergen Boldt [mailto:juergen@omg.org] > Sent: Tuesday, January 18, 2011 4:55 PM > To: issues@omg.org; dds-psm-cxx-ftf@omg.org > Subject: EXTERNAL:issue 15965 -- ISO/IEC C++ DDS PSM FTF issue > > > > Date: Mon, 17 Jan 2011 12:12:37 +0100 > From: Angelo Corsaro > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101218 Thunderbird/3.1.7 > To: DDS-PSM-Java FTF , > DDS-PSM-Cxx FTF , > Richard Warren , Juergen Boldt > Subject: ISSUE: XML-Based QoS Policy Settings (DDS-PSM-Cxx/DDS-PSM-Java) > > Dear All, > > Below the description of an issue that applies to both the DDS-PSM-Cxx and the DDS-PSM-Java. > > > ============================================================================== > > ISSUE > The newly introduced XML Based Policy configuration adds new methods in the core DDS entities that allow to fetch QoS from XML filers. This solution is not ideal since if generalized, e.g. QoS configuration from an URI, JSON stream, etc., would lead to an explosion of the core DDS API. > > The suggestion is to remove the added methods from the core API and use instead a Builder pattern (of some form). > > A sketch of the suggested change is provided below: > > PolicyBuilder builder = PolicyBuilder::load("XMLBuilder"); > > TopicQos tqos = builder.topic_qos(file_name, profile_name); > > ============================================================================== > > Notice that the suggested approach allows to easily extend the supported format for QoS representation w/o any impact on the core DDS API and overall facilitate the support for multiple approaches. > > Cheers, > Angelo > > -- > Angelo Corsaro, PhD > Chief Technology Officer > PrismTech > 4 rue Angiboust | 91460 Marcoussis | France > T +33 1 69 01 53 54 | M +33 6 42 30 75 65 > --------------------------------------------------------------------------------------------------------------------------------------- > http://twitter.com/acorsaro | http://opensplice.blogspot.com | http://slideshare.net/angelo.corsaro > --------------------------------------------------------------------------------------------------------------------------------------- > > > > >