Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
79 lines
2.9 KiB
Text
79 lines
2.9 KiB
Text
Design Process: Builder
|
|
=======================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2008-03-06_
|
|
|*Proposed by* | Ichthyostega
|
|
|====================================
|
|
|
|
Builder within the Steam-Layer
|
|
------------------------------
|
|
One of the core ideas of the Steam-Layer (as being implemented since summer '07
|
|
by Ichthyo) is the use of the Builder-pattern to achieve a separation between
|
|
high-level view and low-level view.
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
The Steam-Layer differentiates into a high-level view, which models the
|
|
properties of the problem domain (manipulating media objects), and a low-level
|
|
model, which is a network of render nodes and will be optimized for processing
|
|
efficiency.
|
|
|
|
In between sits the Builder, which is triggered on all important/relevant
|
|
changes to the high-level model.
|
|
|
|
The Builder inspects the current state of this high-level model and, driven by
|
|
the actual objects and their configuration, creates a corresponding
|
|
representation within the low-level model, which is then hot-swapped into the
|
|
renderer.
|
|
|
|
In the course of this building process, all necessary decisions are taken,
|
|
disabled features and impossible connections are detected and left out, and all
|
|
more elaborate or macro-like structures (e.g. meta clips) are broken down into
|
|
simple building blocks, which can be implemented 1:1 by render nodes in the
|
|
low-level model.
|
|
|
|
The configuration of the high-level model is deliberately very open; the
|
|
builder doesn't impose much limitations, rather he reflects the found
|
|
configuration down into the low-level model using generic rules.
|
|
|
|
Pros
|
|
^^^^
|
|
* Separation, decoupling
|
|
* Architectural aproach instead of just hacking away...
|
|
|
|
Cons
|
|
^^^^
|
|
* Increases the overall complexity
|
|
* More work to be done to get a minimal system implemented
|
|
|
|
Rationale
|
|
~~~~~~~~~
|
|
This design was chosen as a direct consequence of the problems encountered in
|
|
the Cinelerra-2 codebase.
|
|
|
|
* Separating this way allows us to take on different viewpoints on what is
|
|
``good'' and ``efficient''.
|
|
* In the low-level view simplicity and efficiency of computation is the main
|
|
criterion.
|
|
* Whereas in the high-level view a good modeling of the problem domain and
|
|
maximum flexibility is preferable.
|
|
* The high-level view is taken out of the critical code path, allowing for
|
|
advanced and even experimental technologies without endangering the whole
|
|
application's usability. In the low-level realm, _speed_ is measured in ms,
|
|
whereas in the high-level domain, speed is rather measured in 100ms.
|
|
* The separation creates distinct interfaces and allows people with very
|
|
different skill sets to work in parallel at the various levels of the App.
|
|
|
|
|
|
Conclusion
|
|
----------
|
|
This proposal reflects a distinct approach taken right from start.
|
|
|
|
Marked __`final'__ at the
|
|
link:{}/devel/meeting_summary/2008-10-10.html#_the_builder[October.2008 developer meeting]
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|