Summary of Changes to OSSIE since r2923
1-5: Drew Cormier
6-8: Carl Dietrich
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
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
*** 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
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
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 r3295 that merged -r2698:3289
10. Support for componentsupportedinterface in ApplicationFactory?_impl (started with changeset r3683)
11. DEBUG macro (trivial)
12. XML parsers now access xml files via the SCA file system.
注：Summary of Changes to OSSIE since r2923（原文出处，翻译整理仅供参考!）