You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Setting the DomainId for a DomainParticipant via XML is supported by Fast DDS, but it is not intuitive, nor complete.
Lack of Intuitiveness
One common mistake when setting the Domain ID by XML is that users must know they need to use the function create_participant_from_profile instead of create_participant. Additionally, there is no easy way to retrieve the QoS from a profile in order to set a specific value before creating a new DomainParticipant. There is also no straightforward method to obtain the Domain ID in such cases. Although it is possible to retrieve it using XMLProfileManager and the deprecated fastrtps API, this further highlights the lack of intuitiveness.
Incompleteness
While there are ways to use XML configuration to set a default configuration for every Entity in Fast DDS (e.g., configuring all DataReaders as best-effort unless otherwise specified in the code), there is currently no provision for setting the Domain ID through XML configuration.
Use case
It would be desirable to use an XML configuration file to set the Domain ID for every new DomainParticipant created in a specific domain. However, this is currently not possible unless the profile name of such a participant profile is known, and it requires modifying the application code to use a specific API.
This functionality would be similar to the ROS_DOMAIN_ID environment variable.
Proposal
To address the aforementioned issues, it would be more intuitive to include the Domain ID as part of the Domain Participant QoS, as it is essentially another configuration value. This would resolve all the problems described earlier.
This proposed change does not imply an API modification but rather an API extension. Using the existing create_participant function with the Domain ID as an argument would simply overwrite the corresponding QoS value.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Domain Id set by XML
Problem
Setting the DomainId for a DomainParticipant via XML is supported by Fast DDS, but it is not intuitive, nor complete.
Lack of Intuitiveness
One common mistake when setting the Domain ID by XML is that users must know they need to use the function create_participant_from_profile instead of create_participant. Additionally, there is no easy way to retrieve the QoS from a profile in order to set a specific value before creating a new DomainParticipant. There is also no straightforward method to obtain the Domain ID in such cases. Although it is possible to retrieve it using XMLProfileManager and the deprecated fastrtps API, this further highlights the lack of intuitiveness.
Incompleteness
While there are ways to use XML configuration to set a default configuration for every Entity in Fast DDS (e.g., configuring all DataReaders as best-effort unless otherwise specified in the code), there is currently no provision for setting the Domain ID through XML configuration.
Use case
It would be desirable to use an XML configuration file to set the Domain ID for every new DomainParticipant created in a specific domain. However, this is currently not possible unless the profile name of such a participant profile is known, and it requires modifying the application code to use a specific API.
This functionality would be similar to the ROS_DOMAIN_ID environment variable.
Proposal
To address the aforementioned issues, it would be more intuitive to include the Domain ID as part of the Domain Participant QoS, as it is essentially another configuration value. This would resolve all the problems described earlier.
This proposed change does not imply an API modification but rather an API extension. Using the existing create_participant function with the Domain ID as an argument would simply overwrite the corresponding QoS value.
Beta Was this translation helpful? Give feedback.
All reactions