Lumiera is envisaged as a heavyweight yet coherent »Application« — which implies it is not so much seen as “a platform”, framework or operating system. And, in line with this understanding, we place no emphasis on possible configuration changes and state transitions within the running application as a whole. The ability to react “life” to some global setting changes can be limited to relevant special cases. And, while it is indeed possible to close and load a new Session from a running application instance, in most parts of the code base we assume the application just to be “up and running” — all required services are assumed to be available and interfaces to be accessible. If some of these assumptions break, an exception is raised and the application unwinds. Without doubt, these decisions represent a forcible simplification, and might be limiting at times, yet serve us well to cut down complexity in large parts of the code base — however, there needs to be one dedicated realm to deal with all these specific concerns related to configuration, interdependency and lifecyle.
The Vessel
So we treat all these concerns within a focused and self contained structure, called
the »Vessel«, and clearly set apart from all the other layers, services and subsystems.
This dedicated Application Realm is organised around the “Application main object”.
[
This is the singleton vessel::Voyage, which is triggered by the main function
of the Lumiera Application. The sourcecode is kept in a separate folder src/vessel
and linked into the shared library liblumieravessel.so]
Its purpose is to bootstrap and tear-down the application in a controlled way,
which includes to provide the backbone services, evaluate the start-up parameters
and to connect and start the necessary core components. The beginning and end of
this vessel’s voyage therefore marks the Lifecycle of the application, as a
succession of “lifecycle phases” — where almost any activity happens within
the operational phase, when everything is considered “up and running”.
Subsystems
However, before becoming operational, the application must be bootstrapped, and at the end, all parts need to be unwound cleanly. To organise this process, we identify a limited number of Subsystems within the Application, which are self-sufficient and operate independently, at least to some degree. Each Subsystem is self contained and groups some other parts and services, which typically work together and may be mutually dependent. These subsystems represent a grouping, applied for the purpose of starting and stopping the application in a regular way; they rather do not correspond 1:1 to a layer, an interface, a class or a plugin. As a matter of fact, they are rather irrelevant outside the mentioned »Application realm«. A subsystem may depend on other subsystems, which comprises a clear startup- and shutdown-ordering. However, once the application is in normal operational mode, the subsystems turn into a passive, guarding and managing role; the activities relevant for the application’s purpose rather rely on components, interfaces, services, all aggregated into the three Layers »Stage«, »Steam« and »Vault«.
We expect the following subsystems to be built eventually:
Engine, Session, PlayOut, GUI, Script runner, Renderfarm node.
Organisation of Subsystems
Not all subsystems need to be started for any use of the application. A script-driven use, or a renderfarm node does not need a GUI. So there is an overall global operation mode of the application, controlled through the launching options, and determined during the startup phase. It is the responsibility of the Application main object to pull up required functionality, which in turn might result in pulling up further subsystems as dependencies.
Subsystems are defined by implementing the interface vessel::Subsys, which acts
as façade to conduct the lifecycle, find out about dependencies and shut down
the subsystem in the end. So this interface, together with the Subsystem Runner,
define a lifecycle protocol; each subsystem is free to implement this as it
sees fit. Typically, this façade will load plugins, register and provide further
business interfaces, and especially set up the Layer separation interfaces
which canalise any communication going on between the layers.
The GUI Façade is special, while in compliance with this protocol. The actual
UI is loaded from a plug-in at runtime,
[This corresponds to the vision
to allow for different Lumiera UI’s — maybe to support different working styles
or target audiences. If such is actually feasible remains to be clarified as of
2020; even while decoupled on a technical level, the session still needs to make
a lot of assumptions regarding the UI’s capabilities and needs.]
and so the implementation of this façade needs to reside in the application core
realm; it will start a GuiRunner to load and activate the GUI plug-in, which
then in turn has to open the public GUI Notification façade. The latter is
one of the Layer separation interfaces and comprises the actual way for the
lower layers to activate and interact with the user interface.
Parallelism
Actually this scheme builds on the assumption that starting each subsystem will not block the overall start/main/shutdown thread. Any subsystem is supposed to spawn its own control/event threads if necessary. The Lumiera application works fundamentally asynchronous. The user interface operates single threaded, in accordance to long established best practices of UI programming. However, any user interaction is translated into commands, sent down into the session and handled there one by one. The result of processing such commands will be pushed back up into the UI later and detached from the immediate interaction. Likewise, the re-rendering caused by changes in the session is carried out within the engine independently, relying on worker jobs and a thread pool.
Initialisation and Lifecycle
After some discussion,
[
See the GlobalInitialisation RfC
from spring 2008. In the beginning, we all agreed to “keep matters simple”
and build an init() function within one central piece of code everyone knows
and hooks into. However, while the outline of the application emerged, there
was a tension between the concern about over-engineering versus the concern
about tangled and unmanageable complexity. At some point, an alternative
implementation based on lifecycle callbacks was elaborated, which then turned
into the solution described here. At that point, Lumiera ceased to be the
typical UI based application started-up by GTK-main, and the existing GTK
code was retrofitted to be launched from within a plug-in.
]
the design leaned toward loosely coupled parts and a formal lifecycle; which
saves us from investigating and coding up the various interdependencies
explicitly. Rather, all parts of the application have to comply to
Lifecycle Phases,
and each part has to care for its own state transitions, invoked through
lifecycle callbacks. We can distinguish two distinct models how to deal
with lifecycle, and both are equally acceptable:
-
Assuming that operations happen in response to some client’s request, this activation should go through a service interface. Interfaces can be opened and closed in Lumiera, and this is accomplished by hooking them up below some subsystem.
-
However, some parts carry out continuous activities, and in that case a lifecycle hook should be registered, to limit activities to the appropriate lifecycle phase.
Application Start
-
some fundamental language-level facilities will be prepared during static initialisation. At some point, execution enters
main(argc,arvv). -
Voyage::init()brings up the plugin loader and opens the config-interface. -
…followed by triggering ON_GLOBAL_INIT
-
the main thread then pulls up the subsystems (
Voyage::maybeStart(subsystem)), according to the command line options. -
within each subsystem, façade interfaces will be opened through the interface/plug-in system.
-
At this point, the GUI plug-in is loaded and launched, the windows created, the UI event loop starts and the application becomes live.
-
shutdown or failure of any given subsystem initiates the shutdown sequence by requesting all other running subsystems to terminate. In the typical case, the UI subsystem will trigger this shutdown sequence, in response to closing the main window.
-
there is an ON_GLOBAL_SHUTDOWN event, which can be used for normal cleanup; In case of an emergency exit, the ON_EMERGENCY_EXIT event is triggered alternatively.
-
the Voyage destructor tears down the core systems (config-interface and pluginloader).
-
we establish a policy to prohibit any non-local and non-trivial activities during the tear-down phase after leaving the
main()function.