Request for Changes-70: Composite application framework
[Request for Changes - 70] Composite application framework
- Author: Guillaume
- Additional Contributors (if different than authors)
- Submitted on 15.11.2016
- Proposed target release : 5.10
- Adopted (+3 from Julien, Manuel, Guillaume)
- Merged : 36e05abafb5e92f4edfb7caf07f3ed0ce05757c3
This RFC introduces a mechanism to implement composite applications (OTB application that use other OTB application).
Several applications can be re-written as composite applications because the different steps already exists as separate applications.
Classes and files
M Modules/Wrappers/ApplicationEngine/include/otbWrapperParameterGroup.h A Modules/Wrappers/ApplicationEngine/include/otbWrapperProxyParameter.h M Modules/Wrappers/ApplicationEngine/src/CMakeLists.txt M Modules/Wrappers/ApplicationEngine/src/otbWrapperParameterGroup.cxx
The first step was to add a ProxyParameter class : this proxy acts like a symbolic link to a different parameter (which can be in a different application). The proxy doesn't holds a direct pointer to the linked Parameter object, because if the linked parameter also becomes a proxy, then this pointer becomes invalid. Instead, the proxy holds a pointer to the parameter group containing the link and the key of the linked parameter in that group: this is the ProxyTargetType.
In order to operate a replacement of a standard parameter by a proxy, a new function
ReplaceParameter(std::string, Parameter::Pointer) has been added to the class
otb::Wrapper::ParameterGroup. This function adds or substitude a parameter in a group.
The resolution of proxy parameter is done by the static function
ParameterGroup::ResolveParameter(Parameter*). It will follow a parameter until a non-proxy parameter is found. In the application engine, the parameters are accessed using
ParameterGroup::GetParameterByKey(std::string) 99% of the time. So for a transparent handling of proxy parameters, the resolution function is called in this function, which as a new optional parameter to enable/disable proxy parameter resolution :
GetParameterByKey(std::string key, bool follow = true). The 1% other cases are :
- calls to
ParameterGroup::GetParametersKeys(bool): this function will also call the proxy resolution function.
- calls to
ParameterGroup::GetParameterByIndex(unsigned int): like the
GetParameterByKey, an optional argument has been added to enable proxy resolution.
M Modules/Wrappers/ApplicationEngine/include/otbWrapperApplication.h M Modules/Wrappers/ApplicationEngine/src/otbWrapperApplication.cxx
The only settings that should stay attached to the proxy parameter are : its key, its name and its description. This allows to expose an existing parameter through a proxy with a different key, name or description. The base class Application has been updated consequently.
A Modules/Wrappers/ApplicationEngine/include/otbWrapperCompositeApplication.h A Modules/Wrappers/ApplicationEngine/src/otbWrapperCompositeApplication.cxx
Still in the ApplicationEngine, this new class derives from
otb::Wrapper::Application, and it will be used as base class for composite application. It brings some utility functions :
AddApplication(): create, setup and store and internal application. This will also register this internal application with a specific identifier.
ShareParameter(): exposes a parameter of an internal application as a proxy in the composite application.
Connect(): synchronizes two parameters, the first one becomes a proxy toward the second.
ExecuteInternal(): executes an internal application an reports its logs
UpdateInternalParameters(): call the UpdateParameters() function on an internal application.
GetInternalApplication(): returns a pointer to the internal application.
M Modules/Wrappers/ApplicationEngine/test/CMakeLists.txt M Modules/Wrappers/ApplicationEngine/test/otbApplicationEngineTestDriver.cxx M Modules/Wrappers/ApplicationEngine/test/otbWrapperParameterListTest.cxx
The CompositeApplication class can't be instanciated so no testing on this class yet. The proxy parameter is tested in otbWrapperParameterListTest.cxx.
otb::Wrapper::CompositeApplication, two functions (
ShareParameter) use the syntax "app.param" to refer to the parameter key "param" from the internal application "app". This syntax could be generalized for all the functions of
There are at least 2 ways to do that :
Application::GetParameterByKey()virtual and override it in CompositeApplication.
- in CompositeApplication, store a proxy to the parameter list of the internal appplication. But this proxy must be kind of "private", so that its key can't be used in the command line launcher or in the help message.
This generalized access to internal parameters would be a nice addition to the framework, but it deserves a debate. If none of these solutions is good enough, this feature will be adressed in a different RFC.