DDS4CCM_ — ListenerControl

The DDS4CCM spec defines the interface ListenerControl. This is used for the various ports of 8.2.2.2. Some ports (like DDS_RawListen) do specify multiple listen ports, listener and status. There is now just one flag to enable/disable them both. maybe I am just interested in the status and not listener. We propose to move the attribute enabled to each listen interface and remove the ListenerControl interface from the spec. Then each listener can be enabled/disabled independently of each other

The data listening extended ports are defined based on the fact that very often
(not to say all times) an application component which wants to be notified of
modifications of data (listener mode) needs to start by an initialization phase
where he gets all the existing data (and not receive thousands of notifications to
get the data that were existing before its creation). It is why they combine a Data
Listener basic port with a Reader one. Before that init phase is completed, the
component cannot treat well incoming notifications. This is why that
DataListenerControl port is also provided to turn on/off the data 'tap'.
In return, Status Listeners are slightly different in nature: they are there to allow
the component receive errors. The component has no choice with that and
should be in position to get errors even during the init phase! It is the reason why
those are always enabled (enabled at creation and no means / needs to enable
them explicitly).
The recasting of DDS listen ports has added the necessity for two enabled
modes (ONE_BY_ONE and MANY_BY_MANY). In addition, the StateListener is
given a specific control interface allowing in addition to control how filtering in and
out is reflected in the notifications.