The sub and pub plugins now have two redundant methods:
|
virtual std::string getMessageType() const; |
|
virtual std::string getDataType() const = 0; |
Or at least I see them as redundant.
getDataType() is only used in list_transports and PointCloudCodec, but it is a public method which all plugins have to implement.
I'd suggest to deprecate/future remove getDataType() and keep only getMessageType(). In the meantime, we could at least add implementation to simple plugins that would relay getDataType() to getMessageType() so that newly written plugins do not need to implement it. I think this should be ABI-compatible even in existing distros.
The question is whether getDataType() should be removed in the future because it would break all existing plugins. But given the fact that there were anyways large changes recently, the plugin authors have to be prepared for updating....
The sub and pub plugins now have two redundant methods:
point_cloud_transport/point_cloud_transport/include/point_cloud_transport/publisher_plugin.hpp
Line 89 in a6c4497
point_cloud_transport/point_cloud_transport/include/point_cloud_transport/publisher_plugin.hpp
Line 110 in a6c4497
Or at least I see them as redundant.
getDataType()is only used inlist_transportsandPointCloudCodec, but it is a public method which all plugins have to implement.I'd suggest to deprecate/future remove
getDataType()and keep onlygetMessageType(). In the meantime, we could at least add implementation to simple plugins that would relaygetDataType()togetMessageType()so that newly written plugins do not need to implement it. I think this should be ABI-compatible even in existing distros.The question is whether
getDataType()should be removed in the future because it would break all existing plugins. But given the fact that there were anyways large changes recently, the plugin authors have to be prepared for updating....