Issue 6742: Key_separate_from_data Issue (data-distribution-ftf) Source: (, ) Nature: Enhancement Severity: Minor Summary: Issue# 2120 Key_separate_from_data Issue [Boeing SOSCOE] ? Keyed data is important but having the key being part of the data leads to duplication or copying into other types of structures. ? Note that this issue is not too critical. SOSCOE has worked around it by creating a container type that copies the data inside. Proposal [Boeing SOSCOE] ? Split the keys out from the data type. The idea would be to have the write operations take two parameters, one for the data and the other for the key. The same would apply to the reader side. Comment [RTI] ? Maybe this can already be accommodated with a small extension of the DDS API. If we had a DataReader::register_type that took only the key, then we could say that provided that the InstanceHandle_t is passed to the write() operation it is not required for the data to contain the key. ? This issue is exacerbated by the fact that IDL does not allow structures to contain pointers to other structures. If this limitation was not present, then it would reasonable for the user of the DDS API to define a wrapper data-type that would just contain pointers to the Key and to the data-blub. Note that there are other languages’ such as ITU’s ODL (object description language) that are extension to OMG’s IDL and do allow this pointer syntax. However, for now we would have to rely on the individual vendors to implement this feature which would be technically quite simple. ? Separating the key from the data would require DDS that the definition of a Topic would involve not just the specification of the data-type, but also the key-type. Also the implied IDL that represents the type-specific data-writers and data-readers would need to now be generated for each combination of data-type and key-type. There is no standard way to indicate in the IDL file what those combinations are so it would not be so simple for the code-generator to determine this. These problems do not arise if we followed the first approach to allow pointers within the structures. Comment [Boeing SOSCOE] ? The register instance_by_key, would also help this particular scenario. Resolution: Revised Text: Actions taken: December 18, 2003: received issue Discussion: The work-around of writing a container type that SOSCOE has implemented is adequate except that it forces an additional copy of the data and key. This is therefore part of a more general issue of how avoid additional copies when aggregating types into a container type for the purposes of sending it using DDS. The FTF agrees that this is an significant limitation but the resolution would require either the use of value-types or extensions to IDL. These changes are beyond the scope of the FTF. End of Annotations:===== m: webmaster@omg.org Date: 18 Dec 2003 20:42:03 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Matt Liu Company: Boeing mailFrom: matthew.k.liu@boeing.com Notification: Yes Specification: Data Distribution Service for Real-Time Systems Section: 4.1.1.2.2 FormalNumber: Unknown Version: 1.0 RevisionDate: 3/23/03 Page: 14 Nature: Enhancement Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Description Issue# 2120 Key_separate_from_data Issue [Boeing SOSCOE] ? Keyed data is important but having the key being part of the data leads to duplication or copying into other types of structures. ? Note that this issue is not too critical. SOSCOE has worked around it by creating a container type that copies the data inside. Proposal [Boeing SOSCOE] ? Split the keys out from the data type. The idea would be to have the write operations take two parameters, one for the data and the other for the key. The same would apply to the reader side. Comment [RTI] ? Maybe this can already be accommodated with a small extension of the DDS API. If we had a DataReader::register_type that took only the key, then we could say that provided that the InstanceHandle_t is passed to the write() operation it is not required for the data to contain the key. ? This issue is exacerbated by the fact that IDL does not allow structures to contain pointers to other structures. If this limitation was not present, then it would reasonable for the user of the DDS API to define a wrapper data-type that would just contain pointers to the Key and to the data-blub. Note that there are other languages’ such as ITU’s ODL (object description language) that are extension to OMG’s IDL and do allow this pointer syntax. However, for now we would have to rely on the individual vendors to implement this feature which would be technically quite simple. ? Separating the key from the data would require DDS that the definition of a Topic would involve not just the specification of the data-type, but also the key-type. Also the implied IDL that represents the type-specific data-writers and data-readers would need to now be generated for each combination of data-type and key-type. There is no standard way to indicate in the IDL file what those combinations are so it would not be so simple for the code-generator to determine this. These problems do not arise if we followed the first approach to allow pointers within the structures. Comment [Boeing SOSCOE] ? The register instance_by_key, would also help this particular scenario. [OMG ISSUE# 6742, DDS# 72] Key_separate_from_data Issue [Boeing SOSCOE] Ref#2120 Key_separate_from_data Issue Keyed data is important but having the key being part of the data leads to duplication or copying into other types of structures. Note that this issue is not too critical. SOSCOE has worked around it by creating a container type that copies the data inside. Proposal [Boeing SOSCOE] Split the keys out from the data type. The idea would be to have the write operations take two parameters, one for the data and the other for the key. The same would apply to the reader side. Comment [RTI] Maybe this can already be accommodated with a small extension of the DDS API. If we had a DataWriter::register_instance that took only the key, then we could say that provided that the InstanceHandle_t is passed to the write() operation it is not required for the data to contain the key. This issue is exacerbated by the fact that IDL does not allow structures to contain pointers to other structures. If this limitation was not present, then it would reasonable for the user of the DDS API to define a wrapper data-type that would just contain pointers to the Key and to the data-blob. Note that there are other languages. such as ITU.s ODL (object description language) that are extension to OMG.s IDL and do allow this pointer syntax. However, for now we would have to rely on the individual vendors to implement this feature which would be technically quite simple. Separating the key from the data would require DDS that the definition of a Topic would involve not just the specification of the data-type, but also the key-type. Also the implied IDL that represents the type-specific data-writers and data-readers would need to now be generated for each combination of data-type and key-type. There is no standard way to indicate in the IDL file what those combinations are so it would not be so simple for the code-generator to determine this. These problems do not arise if we followed the first approach to allow pointers within the structures. Comment [Boeing SOSCOE] The register instance_by_key, would also help this particular scenario. Concrete changes: Defer since there is a workaround. HANS: what is the work-around? I don.t think we would like the .register_instance_by_key. solution, but I do agree to defer ;) GERARDO: I am just referring to SOSCOE.s comment that it is not too critical because they created a .container that copies the data inside..