search

eProsima / xtypes

Implementation based on DDS-XTYPES standard (https://www.omg.org/spec/DDS-XTypes)
Apache License 2.0
20 stars 10 forks source link

How to use this together with fast-rtps? #82

Open einarhauks opened 4 years ago

einarhauks commented 4 years ago

I cannot find any examples of how to actually publish the xtype data. Is that not supported yet?

LuisGP commented 4 years ago

Hi @einarhauks

Sadly, xtypes isn't supported by Fast-RTPS yet. But Fast-RTPS uses Dynamic Types which currently are more powerful, but offer a bit harder API.

You can find examples using this Dynamic Types in the following links:

The branch feature/xtypes-dds of SOSS-DDS contains an auxiliary Conversion class that allows translating between xtypes and Dynamic Types.

einarhauks commented 4 years ago

Thanks for the reply. Do you have plans to integrate the nice API of xtypes into fast-rtps?

LuisGP commented 4 years ago

Yes! Fast-RTPS 2.1 should make use of the new API.

einarhauks commented 3 years ago

Fast-RTPS is now called FastDDS right? Version v2.2.0 of FastDDS was just released 12 days ago but reading the recent release notes I saw no mentioning of XTypes support. Do you have any new plans for XType support in FastDDS?

jamoralp commented 3 years ago

Hello @einarhauks, Yes, Fast-RTPS is now called Fast-DDS since v2.0.0 release. However, I'm afraid support for this xTypes implementation is not supported yet. Plans have been made to converge our two implementations of DynamicTypes, using all the advantages of Fast-DDS Dynamic Types but providing with the user-friendly API of xtypes. We are already evaluating how much effort should be made to achieve this and actions will be surely taken during this year. Which is your use case? Could you share more specific details that help us understand your interest in this feature? Thanks in advance.

einarhauks commented 3 years ago

Thanks for the quick reply! :)

When I originally wrote this post I was testing data type evolution with FAST-RTPS. Basically compiling a subscriber application and a publisher application separately and then adding new members to the data type on the publisher side put not updating subscriber application. I was hoping that the data type would the "backwards compatible" but I ended up receiving nothing on the subscriber side until I recompiled using the new data type definition. As mentioned, this was a while back and I plan do test this again using the latest version.

So my use-case is basically to support data type evolvement over time. Is that supported today?

jamoralp commented 3 years ago

Well, it is supported using the TypeLookup Service. It is described here: https://fast-dds.docs.eprosima.com/en/latest/fastdds/dynamic_types/discovery.html#typelookup-service and an example is available here: https://fast-dds.docs.eprosima.com/en/latest/fastdds/dynamic_types/examples.html This library still does not implement any of these functionalities. We are studying on how to merge this two xTypes implementations into an external library that Fast-DDS and other external applications can benefit from, but, for now, I hope following that example gives you more information about how to fulfill your task!

einarhauks commented 3 years ago

Following this example: https://github.com/eProsima/Fast-DDS/tree/master/examples/C%2B%2B/DynamicHelloWorldExample I encounter two issues:

  1. Type discovery only works if the publisher is using DynamicTypes as well. I'm able to discover participants (on_participant_discovery) and topics made by all publishers (on_publisher_discovery) but I only get the on_type_information_received and on_type_discovery from publishers that create dynamic types. No type information is received from publishers using types created from an IDL file (based on the HelloWorldExample. This makes working with other DDS systems difficult. Would a type published by another DDS implementation be discoverable or only eProsima Dynamic Types?

  2. By specifying a type in code using DynamicTypeBuilderFactory I'm able to either discover the published type on the subscriber side or define it on the subscriber side in advance and receive data. If I however define it in advance on the subscriber side, then add one member to it on the publisher side, the subscriber is no longer able to receive the data and I get: [XTYPES Warning] Local TypeIdentifier doesn't have a related TypeObject -> Function consistent

One of the features of DDS according to DDS-Foundation is to "Recognize and translate mismatched data types between old and new versions and applications to enable incremental upgrades of large distributed systems" I find it quite hard to achieve using Fast-DDS - am I missing something?