Request for Changes-70: Composite application framework

From OTBWiki
Jump to: navigation, search

[Request for Changes - 70] Composite application framework

Status

  • 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

Summary

This RFC introduces a mechanism to implement composite applications (OTB application that use other OTB application).

Rationale

Several applications can be re-written as composite applications because the different steps already exists as separate applications.

Implementation details

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.

Applications

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.


Tests

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.

Documentation

Additional notes

In otb::Wrapper::CompositeApplication, two functions (Connect and 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 otb::Wrapper::Application.

There are at least 2 ways to do that :

  • make 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.

Retrieved from "https://wiki.orfeo-toolbox.org/index.php?title=Request_for_Changes-70:_Composite_application_framework&oldid=8784"