Issue 6847: DDS ISSUE# 47] Allow application to not specify a timstamp (data-distribution-ftf) Source: Real-Time Innovations (Dr. Gerardo Pardo-Castellote, Ph.D., gerardo(at)rti.com) Nature: Uncategorized Issue Severity: Summary: Ref-157 Ability_of_the_application_to_not_specify_a_timestamp Getting a timestamp can be an expensive operation. It is desirable that the application can configure a datawriter such that it does not get/send the timestamp The option of letting the application not set a timestamp by means of calling write_w_timestamp() and passing TIME_INVALID is not good because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP require this. Also it would be hard to manage if the application could sometimes specify a timestamp and sometimes not for the same DataWriter/instance. ***PROPOSAL*** Add an "receptionTimestamp" field to the SampleInfo. Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers. Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP. The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED. And is set on both the DataWriter and the DataReader and also on Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED. The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has a kind that can be NOT_PROVIDED and PROVIDED. The SOURCE _TIMESTAMP indicates that data must be timestamped when sent. The RECEPTION_TIMESTAMP indicates that data must be timestamped when received. DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE QoS. If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write operation does not put any timestamp and the xxx_w_timestamp operation silently ignores the timestamp and behaves normally. Upon reception the sourceTimestamp field in the SampleInfo will be TIME_INVALID If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will automatically get the timestamp by some means (i.e. the middleware will do it), the xxx_w_timestamp will allow the application to provide the timestamp. In either case the data will be sent with a timestamp and the SampleInfo.sourceTimestamp field will never be TIME_INVALID It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is the relative order and that does not require to get a true timestamp. If this is too confusing we could rename BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER If RECEPTION_TIMESTAMP is NOT_PROVIDED then the SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise it will never be TIME_INVALID By default the source-timestamp is provided. 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. Offering this facility would require many changes to the specification and it is not clear how important this would be to users of the specification. This feature could be included in a future revision of the once the need and requirements are better defined. End of Annotations:===== ISSUE# 47] Allow application to not specify a timstamp ***Ref-157 Ability_of_the_application_to_not_specify_a_timestamp Getting a timestamp can be an expensive operation. It is desirable that the application can configure a datawriter such that it does not get/send the timestamp The option of letting the application not set a timestamp by means of calling write_w_timestamp() and passing TIME_INVALID is not good because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP require this. Also it would be hard to manage if the application could sometimes specify a timestamp and sometimes not for the same DataWriter/instance. ***PROPOSAL*** Add an "receptionTimestamp" field to the SampleInfo. Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers. Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP. The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED. And is set on both the DataWriter and the DataReader and also on Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED. The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has a kind that can be NOT_PROVIDED and PROVIDED. The SOURCE _TIMESTAMP indicates that data must be timestamped when sent. The RECEPTION_TIMESTAMP indicates that data must be timestamped when received. DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE QoS. If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write operation does not put any timestamp and the xxx_w_timestamp operation silently ignores the timestamp and behaves normally. Upon reception the sourceTimestamp field in the SampleInfo will be TIME_INVALID If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will automatically get the timestamp by some means (i.e. the middleware will do it), the xxx_w_timestamp will allow the application to provide the timestamp. In either case the data will be sent with a timestamp and the SampleInfo.sourceTimestamp field will never be TIME_INVALID It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is the relative order and that does not require to get a true timestamp. If this is too confusing we could rename BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER If RECEPTION_TIMESTAMP is NOT_PROVIDED then the SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise it will never be TIME_INVALID By default the source-timestamp is [OMG ISSUE# 6847, DDS# 47] Allow application to not specify a timestamp Ref-157 Ability_of_the_application_to_not_specify_a_timestamp Getting a timestamp can be an expensive operation. It is desirable that the application can configure a datawriter such that it does not get/send the timestamp The option of letting the application not set a timestamp by means of calling write_w_timestamp() and passing TIME_INVALID is not good because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP require this. Also it would be hard to manage if the application could sometimes specify a timestamp and sometimes not for the same DataWriter/instance. ***PROPOSAL*** Add an .receptionTimestamp. field to the SampleInfo. Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers. Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP. The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED. And is set on both the DataWriter and the DataReader and also on Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED. The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has a kind that can be NOT_PROVIDED and PROVIDED. The SOURCE _TIMESTAMP indicates that data must be timestamped when sent. The RECEPTION_TIMESTAMP indicates that data must be timestamped when received. DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE QoS. If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write operation does not put any timestamp and the xxx_w_timestamp operation silently ignores the timestamp and behaves normally. Upon reception the sourceTimestamp field in the SampleInfo will be TIME_INVALID If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will automatically get the timestamp by some means (i.e. the middleware will do it), the xxx_w_timestamp will allow the application to provide the timestamp. In either case the data will be sent with a timestamp and the SampleInfo.sourceTimestamp field will never be TIME_INVALID It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is the relative order and that does not require to get a true timestamp. If this is too confusing we could rename BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER If RECEPTION_TIMESTAMP is NOT_PROVIDED then the SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise it will never be TIME_INVALID By default the source-timestamp is provided. New comments: These seem like a lot of changes for something that is perhaps a small improvement. RTI, the original submitters of this issue now thinks that it is not worth offering this capability at this point. At the 24-feb-04 FTF teleconference it was agreed that it is best not to make this change now. Concrete changes: NONE The new proposal is to NOT change the specification and leave the issue for some future revision. [OMG ISSUE# 6847, DDS# 47] Allow application to not specify a timestamp Ref-157 Ability_of_the_application_to_not_specify_a_timestamp Getting a timestamp can be an expensive operation. It is desirable that the application can configure a datawriter such that it does not get/send the timestamp The option of letting the application not set a timestamp by means of calling write_w_timestamp() and passing TIME_INVALID is not good because certain QoS such as DESTINATION_ORDER BY_SOURCE_TIMESTAMP require this. Also it would be hard to manage if the application could sometimes specify a timestamp and sometimes not for the same DataWriter/instance. ***PROPOSAL*** Add an .receptionTimestamp. field to the SampleInfo. Make the DESTINATION_ORDER also an offered QoS on the DataWriter. For compatibility BY_SOURCE_TIMESTAMP>BY_DESTINATION_TIMESTAMP, that is if you offer SOURCE_TIMESTAMP you can accommodate both kinds or readers. Add the QoS WRITER_TIMESTAMP and READER_TIMESTAMP. The SOURCE_TIMESTAMP has a kind that can be NOT_PROVIDED and PROVIDED. And is set on both the DataWriter and the DataReader and also on Topic. It has request/offered semantics where PROVIDED > NOT_PROVIDED. The RECEPTION_TIMESTAMP is only set in the DataReader or Topic and has a kind that can be NOT_PROVIDED and PROVIDED. The SOURCE _TIMESTAMP indicates that data must be timestamped when sent. The RECEPTION_TIMESTAMP indicates that data must be timestamped when received. DESTINATION_ORDER BY_SOURCE_TIMESTAMP requires that the SOURCE _TIMESTAMP is set to PROVIDED otherwise we will flag an INCOMPATIBLE QoS. If SOURCE _TIMESTAMP.kind== NOT_PROVIDED, then the DataWriter ::write operation does not put any timestamp and the xxx_w_timestamp operation silently ignores the timestamp and behaves normally. Upon reception the sourceTimestamp field in the SampleInfo will be TIME_INVALID If SOURCE _TIMESTAMP.kind== PROVIDED, then the write operation will automatically get the timestamp by some means (i.e. the middleware will do it), the xxx_w_timestamp will allow the application to provide the timestamp. In either case the data will be sent with a timestamp and the SampleInfo.sourceTimestamp field will never be TIME_INVALID It is allowed for RECEPTION_TIMESTAMP to be NOT_PROVIDED and the the DESTINATION_ORDER to be BY_RECEPTION_TIMESTAMP because what matter is the relative order and that does not require to get a true timestamp. If this is too confusing we could rename BY_RECEPTION_TIMESTAMP to be BY_RECEPTION_ORDER If RECEPTION_TIMESTAMP is NOT_PROVIDED then the SampleInfo.receptionTimestamp will always be TIME_INVALID. Otherwise it will never be TIME_INVALID By default the source-timestamp is provided. New comments: These seem like a lot of changes for something that is perhaps a small improvement. RTI, the original submitters of this issue now thinks that it is not worth offering this capability at this point. At the 24-feb-04 FTF teleconference it was agreed that it is best not to make this change now. Concrete changes: NONE The new proposal is to NOT change the specification and leave the issue for some future revision. provided.