DDS11 — DDS 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
provided.