It isn’t necessarily an optimisation from the point of view of a lot of DDS use cases. The lack of need for a central discovery daemon was a major design goal in the way DDS works.
However, there are use cases where it is an optimisation, as you say. Perhaps using that optimisation, when it’s available, via rmw, and providing our own daemon as part of the rmw implementation when it’s not, is a valid implementation.
Thoughts on this approach?
Does anyone (@iluetkeb) have any data on which DDS implementations provide a list of available topics in near-instant time, and which do not? Remember that providing access to the list of topics seen by the participant since it started is not the same thing as what we need. We need something that accumulates the list of topics currently available, including those that the rostopic tool may not have seen itself, and can provide that list on demand. So far the CoreDX implementation that @iluetkeb mentioned sounds like it provides this functionality already, but I’m not aware of any others that do.
One of the reasons for choosing a well-known topic was so that discovery can be short-circuited in DDS implementations that support it.