DDS — DDS ISSUE# 33] Initialization of resources needed

] Initialization of resources needed to implement
DURABILITY TRANSIENT or PERSISTENT

***Ref-91 Configuration_of_the_transient_and_persistent_service

The DDS specification does not provide a clear model of the behavior
of the service when the DURABILITY QoS is set to TRANSIENT or
PERSISTENT

Moreover for the application needs to be able to specify the QoS
parameters and resources that the implementation is allowed to use
when implementing this service.

**PROPOSAL**

Add the following explanation to section 2.1.3.2:

For the purpose of implementing the the DURABILITY QoS settings of
TRANSIENT, PERSISTENT the service behaves "as if" it had a "built-in
DataReader and DataWriter" for each Topic that is configured to have
said DURABILITY kind. In other words, it is "as if" somewhere in the
system (possibly on a remote node) there was a "built-in durability"
DataReader that subscribed to that Topic and a "built-in durability"
DataWriter that published that Topic as needed for the new subscribers
that join the system.

For each Topic, the built-in "persistence service"
datareader/datawriter has its QoS configured from the Topic QoS for
that Topic as described in Issue Topic_qos_refactor (Issue #86). In
otherwords, it is as-if the service first did a
"Participant::lookup_topic" for that Topic, and then used the QoS on
the Topic to configure the built-in entities.

As a consequence of this model, the transient or persistence serviced
can be configured by means of setting the proper QoS on the Topic.

For a given Topic, the usual request/offered semantics apply to the
matching between any DataWriter in the system that writes the Topic
and the built-in transient/persistent DataReader for that
Topic. Similarly for the builtin transient/persistent DataWriter for
the Topic and any DataReader for the Topic. As a consequence, a
DataWriter that has an incompatible QoS with respect to what the Topic
specified for the built-in transient/persistent DataReader will not
send its data to the transient/persistent service, and a DataReader
that has incompatible QoS with respect to the specified in the Topic
for the transient/persistent DataWriter will not get data from it.

Incompatibilities between local DataReader/DataWriter entities and the
corresponding builtin transient/persistent entities cause the
"incompatible qos" listener to be invoked as they would with any other
entity.

see below