Issue 6850: DDS ISSUE# 50] Multiple observers sharing a datareader (data-distribution-ftf) Source: Real-Time Innovations (Dr. Gerardo Pardo-Castellote, Ph.D., gerardo(at)rti.com) Nature: Uncategorized Issue Severity: Summary: Ref-166 Allow_multiple_observers_on_a_datareader Currently there can only be one "observer" on each DataReader. In other words, it is not possible to have some independent application observe the data that a DataReader gets without at the same time affecting the sample-state and this the behavior of other data-readers. It is often the case that debugging tool, an interceptor or some other utility would like to access the data available on the DataReader without making its presence noted and thus changing the behavior of other readers. This is particularly relevant for the built-in topics. ***PROPOSAL*** Add an operation: DataReader:: create_view that returns a DataReader. This affects 2.2.2.4.1 and the IDL in 2.2.3 This DataReader is a view on the same DataReader so it has the same QoS and listeners. The application can use the original DataReader or a view to perform any operations allowed on a DataReader. A change of QoS or listener in one view or on the main object affects the main object and all views. Read and Take operations act independently on each view. The application must take the data from all views before it can be removed from the infrastructure and the resources reclaimed. Resolution: Revised Text: Actions taken: December 23, 2003: received issue Discussion: Resolution: The FTF recognizes that this would be a useful facility. However the FTF has resolved to not modify the specification. This concept significantly complicates the model and the value of it remains unclear. This feature could be included in a future revision of the once the need and requirements are better defined. End of Annotations:===== ISSUE# 50] Multiple observers sharing a datareader ***Ref-166 Allow_multiple_observers_on_a_datareader Currently there can only be one "observer" on each DataReader. In other words, it is not possible to have some independent application observe the data that a DataReader gets without at the same time affecting the sample-state and this the behavior of other data-readers. It is often the case that debugging tool, an interceptor or some other utility would like to access the data available on the DataReader without making its presence noted and thus changing the behavior of other readers. This is particularly relevant for the built-in topics. ***PROPOSAL*** Add an operation: DataReader:: create_view that returns a DataReader. This affects 2.2.2.4.1 and the IDL in 2.2.3 This DataReader is a view on the same DataReader so it has the same QoS and listeners. The application can use the original DataReader or a view to perform any operations allowed on a DataReader. A change of QoS or listener in one view or on the main object affects the main object and all views. Read and Take operations act independently on each view. The application must take the data from all views before it can be removed Issue 6850 This issue is outside the 21feb batch. We talked briefly about some proposals to resolve it. A full document will follow by Feb 26 with the concrete proposal for that and there rest of the issues in the next batch. [OMG ISSUE# 6850, DDS# 50] Multiple observers sharing a datareader Ref-166 Allow_multiple_observers_on_a_datareader Currently there can only be one .observer. on each DataReader. In other words, it is not possible to have some independent application observe the data that a DataReader gets without at the same time affecting the sample-state and this the behavior of other data-readers. It is often the case that debugging tool, an interceptor or some other utility would like to access the data available on the DataReader without making its presence noted and thus changing the behavior of other readers. This is particularly relevant for the built-in topics. ***PROPOSAL*** Add an operation: DataReader:: create_view that returns a DataReader. This affects 2.1.2.5.3 and the IDL in 2.2.3 This DataReader is a view on the same DataReader so it has the same QoS and listeners. The application can use the original DataReader or a view to perform any operations allowed on a DataReader. A change of QoS or listener in one view or on the main object affects the main object and all views. Read and Take operations act independently on each view. The application must take the data from all views before it can be removed from the infrastructure and the resources reclaimed. Concrete changes: Section 2.1.2.5.3 DataReader Class DataReader table: Add operation: Name: create_view Parameter: a_listener DataReaderListener Return: DataReader Add section 2.1.2.5.3.21 2.1.2.5.3.21 create_view This operation creates a new .duplicated. view of the DataReader. The new view provides a facade to the same underlying subscription sharing only QoS and resources with the original DataReader. More than one view can be created by successive calls to create_view on the original DataReader or any of the existing views. Although the specification imposes no limits on the maximum number of views associated with a single DataReader, implementations can limit the number. However, all implementations must support the creation of at least one view. There is no application-visible distinction between the original DataReader and the subsequently-created views. In essence the original DataReader is just one more view. This description we will refer to all of them as views. Each view can be used independently of each other to access the data. In other words, the fact that the application reads or takes data using one view does not affect the other views. Each view will see the samples, lifecycle and sample states as if it was the only view. If the application uses the .take. operation to access samples; those same samples will no longer be accessible to the view. They will, however, be accessible to the other views. All views must therefore .take. the sample before the service can reclaim the resources needed to manage the sample. All views are associated with the same underlying subscription so if the QoS is changed using any of the views they will all be affected by the change. Each view has its own separate listener, communication status and status_condition. In this manner the application can interact with each view independently. As stated, the only coupling occurs in terms of the underlying data-resources and QoS. Each view must be enabled separately. The similar to the behavior of the Subscriber operation create_datareader, the operation create_view will automatically enable the newly created view if and only if the ENTITY_FACTORY QoS for the Subscriber has the autoenable_created_entities flag set to TRUE. The application must explicitly delete each view by means of the delete_datareader operation on the Subscriber for the underlying resources to be reclaimed. As long as there is one view the subscription to the Topic will remain. Section 2.2.3 DCPS PSM : IDL DataReader interface: Add operation: DataReader create_view(in DataReaderListener a_listener); [OMG ISSUE# 6850, DDS# 50] Multiple observers sharing a datareader Ref-166 Allow_multiple_observers_on_a_datareader Currently there can only be one .observer. on each DataReader. In other words, it is not possible to have some independent application observe the data that a DataReader gets without at the same time affecting the sample-state and this the behavior of other data-readers. It is often the case that debugging tool, an interceptor or some other utility would like to access the data available on the DataReader without making its presence noted and thus changing the behavior of other readers. This is particularly relevant for the built-in topics. ***PROPOSAL*** Add an operation: DataReader:: create_view that returns a DataReader. This affects 2.1.2.5.3 and the IDL in 2.2.3 This DataReader is a view on the same DataReader so it has the same QoS and listeners. The application can use the original DataReader or a view to perform any operations allowed on a DataReader. A change of QoS or listener in one view or on the main object affects the main object and all views. Read and Take operations act independently on each view. The application must take the data from all views before it can be removed from the infrastructure and the resources reclaimed. Concrete changes: Section 2.1.2.5.3 DataReader Class DataReader table: Add operation: Name: create_view Parameter: reset_state boolean Parameter: a_listener DataReaderListener Return: DataReader Add section 2.1.2.5.3.21 2.1.2.5.3.21 create_view This operation creates a new .duplicated. view of the DataReader. The new view provides a facade to the same underlying subscription sharing only QoS and resources with the original DataReader. The parameter reset_state controls the initial state of the view: If reset_state is TRUE the view is initialized as if no data was ever accessed by the .parent. DataReader. If reset_state is FALSE the view is initialized by copying the .parent. DataReader status as well as the sample_state, view_state, and instance_state for the already received samples and instances. Refer to Section 2.1.2.5.1 for a description of these states. More than one view can be created by successive calls to create_view on the original DataReader or any of the existing views. Although the specification imposes no limits on the maximum number of views associated with a single DataReader, implementations can limit the number. However, all implementations must support the creation of at least one view. There is no application-visible distinction between the original DataReader and the subsequently-created views. In essence the original DataReader is just one more view. This description will refer to all of them as views. Each view can be used independently of each other to access the data. In other words, the fact that the application reads or takes data using one view does not affect the other views. If the application uses the .take. operation to access samples; those same samples will no longer be accessible to the view. They will, however, be accessible to the other views. All views must therefore .take. the sample before the service can reclaim the resources needed to manage the sample. All views are associated with the same underlying subscription so if the QoS is changed using any of the views they will all be affected by the change. Each view has its own separate listener, communication status and status_condition. In this manner the application can interact with each view independently. As stated, the only coupling occurs in terms of the underlying data-resources and QoS. Each view must be enabled separately. Similar to the behavior of the Subscriber operation create_datareader, the operation create_view will automatically enable the newly created view if and only if the ENTITY_FACTORY QoS for the Subscriber has the autoenable_created_entities flag set to TRUE. The application must explicitly delete each view by means of the delete_datareader operation on the Subscriber for the underlying resources to be reclaimed. As long as there is one view the subscription to the Topic will remain. Section 2.2.3 DCPS PSM : IDL DataReader interface: Add operation: DataReader create_view(in boolean reset_state, in DataReaderListener a_listener); [OMG ISSUE# 6850, DDS# 50] Multiple observers sharing a datareader Ref-166 Allow_multiple_observers_on_a_datareader Currently there can only be one .observer. on each DataReader. In other words, it is not possible to have some independent application observe the data that a DataReader gets without at the same time affecting the sample-state and this the behavior of other data-readers. It is often the case that debugging tool, an interceptor or some other utility would like to access the data available on the DataReader without making its presence noted and thus changing the behavior of other readers. This is particularly relevant for the built-in topics. ***PROPOSAL*** Add an operation: DataReader:: create_view that returns a DataReader. This affects 2.1.2.5.3 and the IDL in 2.2.3 This DataReader is a view on the same DataReader so it has the same QoS and listeners. The application can use the original DataReader or a view to perform any operations allowed on a DataReader. A change of QoS or listener in one view or on the main object affects the main object and all views. Read and Take operations act independently on each view. The application must take the data from all views before it can be removed from the infrastructure and the resources reclaimed. Correction, each view has its own listener so setting a listener in one view does not affect the others. Detailed proposal: Section 2.1.2.5.3 DataReader Class Add section 2.1.2.5.3.21 2.1.2.5.3.21 create_view This operation creates a new .duplicated. view of the DataReader. The new view provides a facade to the same underlying subscription sharing only QoS and resources with the original DataReader. The parameter reset_state controls the initial state of the view: If reset_state is TRUE the view is initialized as if no data was ever accessed by the .parent. DataReader. If reset_state is FALSE the view is initialized by copying the .parent. DataReader status as well as the sample_state, view_state, and instance_state for the already received samples and instances. Refer to Section 2.1.2.5.1 for a description of these states. More than one view can be created by successive calls to create_view on the original DataReader or any of the existing views. Although the specification imposes no limits on the maximum number of views associated with a single DataReader, implementations can limit the number. However, all implementations must support the creation of at least one view. There is no application-visible distinction between the original DataReader and the subsequently-created views. In essence the original DataReader is just one more view. This description will refer to all of them as views. Each view can be used independently of each other to access the data. In other words, the fact that the application reads or takes data using one view does not affect the other views. If the application uses the .take. operation to access samples; those same samples will no longer be accessible to the view. They will, however, be accessible to the other views. All views must therefore .take. the sample before the service can reclaim the resources needed to manage the sample. All views are associated with the same underlying subscription so if the QoS is changed using any of the views they will all be affected by the change. Each view has its own separate listener, communication status and status_condition. In this manner the application can interact with each view independently. As stated, the only coupling occurs in terms of the underlying data-resources and QoS. Each view must be enabled separately. Similar to the behavior of the Subscriber operation create_datareader, the operation create_view will automatically enable the newly created view if and only if the ENTITY_FACTORY QoS for the Subscriber has the autoenable_created_entities flag set to TRUE. The application must explicitly delete each view by means of the delete_datareader operation on the Subscriber for the underlying resources to be reclaimed. As long as there is one view the subscription to the Topic will remain. Section 2.2.3 DCPS PSM : IDL DataReader interface: Add operation: DataReader create_view(in boolean reset_state, in DataReaderListener a_listener); Concrete changes: Do not modify the specification. This concept significantly complicates the model and the value of it remains unclear. Leave it out of the specification and once the need is more clear it could be added in a future revision. from the infrastructure and the resources reclaimed.