|
From: Adam M. <mi...@ob...> - 2020-01-29 00:12:47
|
Hi Tom, Let me expand a bit on what Fred wrote... DDS depends on knowing about the data structure for each topic. This enables QoS processing, reliability support in the rtps_udp transport, and content filtering. This is a fundamental difference from other Publish/Subscribe systems that are not Data-Centric (referring to the DCPS term from the DDS spec). One approach, as Fred mentioned, is to use an opaque data type to hide the protobuf data from DDS. This is possible but can be seen as contrary to the design goals of DDS so you get some friction or "impedance mismatch." Another approach would be to enhance OpenDDS to inherently know about protobuf serialization and allow for keys, content filtering, etc. It is hard to answer a "how difficult" question for this one, but it should be possible. In the end, what you decide to do will depend on the overall distributed application design and how it has to integrate with other systems. We can help you with this, but it's beyond the scope of this mailing list. Thanks, Adam On 1/28/2020 6:00 PM, Fred Hornsey wrote: > It wouldn't be difficult at all. You'd still need to use at least one > IDL struct, but it can just contain an octetseq field that you can > fill with the serialized protobuf data. You'd lose any DDS features > that rely on reading sample data of course. > > Fred Hornsey > > On Tue, Jan 28, 2020 at 5:41 PM Thomas Maslach via opendds-main > <ope...@li... > <mailto:ope...@li...>> wrote: > > Hi, > > How difficult would it be to use Google Protocol Buffers for > serialization/deserialization instead of idl? > > Thanks! > > Tom > > _______________________________________________ > opendds-main mailing list > ope...@li... > <mailto:ope...@li...> > https://lists.sourceforge.net/lists/listinfo/opendds-main > > > > _______________________________________________ > opendds-main mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opendds-main |