Change in IDL Files on running application

4 posts / 0 new
Last post
Offline
Last seen: 7 years 5 months ago
Joined: 04/26/2017
Posts: 2
Change in IDL Files on running application

Hey guys,

i am pretty new to the concept off dds.
And i wasn't able to find information on how you handle later changes on data types and idl files on a running application. Do you really have to recompile the application everytime? Or dou you use dll files or something?

Thanks for your information!

Best regards,

Max

rip
rip's picture
Offline
Last seen: 2 weeks 4 days ago
Joined: 04/06/2012
Posts: 324

Hi Max,

Once a system is "live" you should not really see incremental changes of the IDL.  The IDL itself is only used during development stages, there is a compiler (rtiddsgen) that will take the IDL and generate from it the various source files that, when compiled, provide for instances of the data types, as well as the typed readers and writers (and marshaling, etc) for that type.

Because the data types are seen as fully qualified peers of the distributed system, an application should be very careful about changes to the IDL for the data types, because if you change the IDL, regenerate the source, compile it into the new application ... you will not be able to talk to any application that still uses the old IDL types*.

* [sidebar] I keep putting asterisks because there are different levels of truth here :)  If you are using "extensible types", a type can evolve over time, and applications will still be able to extract what information they can from the available data, based on the state of the data type when they were compiled.  This is a different discussion, and while extensible types are a thing, it is better, when starting out, to simply assume that the datatype is "fixed" and treat it as such.  When XTypes talk about "evolve over time" they are not talking about next week, or about 2.0 to 2.1.  More likely you are talking 1.0 to 2.0 to 4.0 to 8.0 -- years between iterations is more likely.

So, to answer your question:

Yes, you really do recompile your application if the data type changes.  During early development of new IDL, you can iterate very quickly until you reach something stable, and from that point lock it down and require a change-order and sign-off by higher before you let someone tweak the IDL.  Because once an application is deployed and talking to other applications, if you change the IDL you break that conversation unless all the other applications are updated at the same time -- which is sort of counter to what DDS is designed to provide (publishers and subscribers can be updated as/if/when, and so long as they still use the same types, altering one does not force updating all the rest.

rip

Offline
Last seen: 7 years 5 months ago
Joined: 04/26/2017
Posts: 2

Hello rip,

Thank you very much for your answer. That helped me a lot. But besides that, is it useful to put the idl generated code into libraries to use them on multiple systems? Or what is the best practice here?

Best regards,

Max

rip
rip's picture
Offline
Last seen: 2 weeks 4 days ago
Joined: 04/06/2012
Posts: 324

I don't see why not.  Generating in a single build environment and then making them available as artifacts for multiple systems is certainly and accepted CompSci strategy. 

If you are working under source control, treating the generated files as artifacts of the build, and only storing the IDL under version control is the clever thing to do, but you have to insist on not letting your engineers muck about with the auto-generated code.

In java, I spent a lot of time "wrapping" generated code by sub-classing the ones I really need, and then doing any changes in the sub-class rather than the auto-generated stuff.