|Version 3 (modified by balister, 6 years ago)|
Summary of Changes to OSSIE since r2923
1-5: Drew Cormier
6-8: Carl Dietrich
9-11: Joseph Gaeddert
In the newest version of the framework GPP makes a local copy of each component's binary file. This approach lends itself to distributed computing. However, GPP only makes a copy of a single file, which is a problem for components whose executable code is a collection of files (e.g., Python components). There are many approaches to resolving this problem:
- Make another device (e.g., Python_GPP) that is capable of copying a directory of files and executing the appropriate main file (e.g., main.py). Each Python component has to be deployed onto Python_GPP instead of GPP.
- Add the capability to move and execute a Python package to the existing GPP.
- Combine all python files in the package into a single .py file.
- Revert to the old GPP
I have used approaches C and D successfully. Implementing A or B may take a fair amount of work.
2. Component Naming Contexts.
When querying the framework for the name of a component, the framework now returns the component name instance without the waveform name instance. Connections can still be established between waveforms by sending the framework a ***application*** instance name, a component instance name, and a port instance name, but the ***application*** instance name has to be retreieved separately through the application's name attribute.
*** Corrections to #2: I am removing the comment "I believe this change was made for SCA compliance." It appears that the original interpretation, though not explicitly stated in the SCA, is in fact SCA compliant. Also, the "waveform instance name" I was referring to is in reality the "application instance name".
3. Creating multiple instances of a waveform.
With the older version of the framework multiple copies of a single waveform are established by sending a single SAD file to the framework multiple times. Each time a SAD file is sent, a new application factory is created with a unique name generated by the framework.
*** I neglected to mention that with the older version of the framework it is also possible, and often recommended, to call create() multiple times on an application factory. The application factory name that was generated, along with the application names are NOT unique in the old framework. The name in the naming service IS unique. The old framework was responsible for guaranteeing uniqueness in the naming context.
With the new version of the famework it is up to the user to generate unique names for the application factory (through a unique SAD file name) OR the application (through a unique name sent to the create() method). The only potentially fatal problem I could see with this is if machine_1 tries to create "my_waveform_1" and "my_waveform_2" at the same time machine_2 tries to create "my_waveform_2" and "my_waveform_3".
The user can still query the framework for a list of available applications, which all have the same unique names that they were given when create() was called.
*** As with item 2, I am removing the "This change was made for SCA compliance" statement from item 3. The old method does not violate the SCA since the application name in the naming context is guaranteed to be unique.
4. Absence of waveform subdirectories
c_waveloader and the latest ALF assume that each xxx.sad.xml has a corresponding yyy_DAS.xml, where xxx == yyy. This has to be the case since the waveform XML files no longer lie in subdirectories. In other words: /sdr/dom/waveforms has no subdirectories. I'm not really sure why this was done. I don't see any problem with it.
5. Necessary changes to components
The directories in my_component.spd.xml that point to the component's XML files and binary files are different. This change is not a problem from my perspective.
The arguments passed to the component during runtime (argc/argv) are different, and an instance of ossieComponent is created in the main.cpp file. I'm not entirely sure why this is necessary, but so far it does not seem to be a big deal.
6. Elimination of framework dependency of Xerces
7. Elimination of wavLoader dependency on Amara
8. Elimination of OWD dependency on Amara
9. FileManager? is restructured. Uses the boost filesystem for basic file operations (moving, querying properties, etc.). Migrates towards SCA compliance by throwing exceptions when necessary. This has been verified with the JTAP tool. Most of these changes were introduced with changeset 3295 that merged -r2698:3289
10. Component supported interface support in ApplicationFactory?_impl (started with changeset 3683)
11. DEBUG macro (trivial)
12. XML parsers now access xml files via the SCA file system.