Issue 12465: 'synchrobnous' and 'asynchronous' switched (data-distribution-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchrobnous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec. <para #4, page 11> On the subscriber’s side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access. Resolution: Revised Text: Actions taken: May 14, 2008: received issue Discussion: End of Annotations:===== ubject: DDS RTF Issue - Specify the allowed IDL Types within DDS Topic structs Date: Mon, 31 Mar 2008 16:27:23 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DDS RTF Issue - Specify the allowed IDL Types within DDS Topic structs Thread-Index: AciTdgBsbSVykFbMSM20qJXwc2MwQA== From: "Fudge, Charles L CIV NSWCDD, W23" To: Cc: "Werme, Paul V CIV NSWCDD, W13" , "Madden, Leslie A CIV NSWCDD, W13" X-OriginalArrivalTime: 31 Mar 2008 21:27:26.0032 (UTC) FILETIME=[03DD5500:01C89376] Issue: The DDS Spec (as of v1.2) does not specify the set of IDL types that are allowed in a DDS Topic struct. This should be defined and made normative instead of being left as an implementation detail. Discussion: Because the set of IDL types allowed in a DDS Topic struct is not defined, implementors are at liberty to decide what set of IDL types to support. Concerns about the impact of the lack of standardization in this area have been raised by the computing infrastructure teams on major Navy programs on several occasions particularly in regards to potential impact on code portability across DDS implementations and interoperability between DDS implementations. In reviewing the DDS C++ Native Language Mapping RFP, we commented that the RFP provided an opportunity to insert a requirement to define the allowed C++ types within a DDS Topic struct which would indirectly result in defining the set of allowed DDS IDL types due to the RFP requirement for the C++ mapping to be consistent with the IDL mapping. This suggestion was rejected because it was viewed that the correct forum and mechanism for resolving this issue was the DDS RTF. We were requested to submit this as an issue to the RTF since the RTF could probably resolve this issue within the next 6 months.