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.
81 lines
3.6 KiB
Text
81 lines
3.6 KiB
Text
Architecure Overview
|
|
====================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2008-03-06_
|
|
|*Proposed by* | Ichthyostega
|
|
|====================================
|
|
|
|
Architecure Overview
|
|
--------------------
|
|
This proposal intends to capture envisioned Architecture of the Application.
|
|
|
|
image:{ldoc}/devel/draw/rendered/Lumi.Architecture-1.png[Overview of Lumiera Architecture]
|
|
|
|
^The SVG source of this drawing is
|
|
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]·
|
|
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=HEAD[(current: 2022)]^
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
* the Application has three Layers: Vault, Steam and Stage.footnote:[at the
|
|
time of this writing, those three layers were named ``Backend'', ``Proc'' and ``GUI'']
|
|
* the Application shall be completely functional without GUI (script-driven)
|
|
* all IO, media data fetching, processing and bookkeeping falls within the
|
|
realm of the Vault Layer
|
|
* all media object manipulation, deciding and configuration is the Steam
|
|
Layer's job
|
|
* extensible by plugins on all levels, highly configurable, but not totally
|
|
componentized (micro kernel) architecture
|
|
* strong separation between high-level and low-level areas of the Application
|
|
* the user/GUI manipulates a high-level model whereas rendering is based on a
|
|
corresponding low-level model
|
|
* stored Session (state) is comprised of high-level model, a collection of
|
|
Assets and accompanying configuration
|
|
* (possibly) several storage backends, abstracted out by a common interface
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
* Alcarinque made link:/x/Proposal.Alcarinque.html[some design drafts] for the UI. +
|
|
This is not a technical draft at all, it is just an idea.
|
|
|
|
* Wouldn't the Config Rules (embedded Prolog) also interact with the High
|
|
Level Model? Or would that be expanding its scope too much? I imagine
|
|
default/user configurable settings such as explicit !LocatingPin placement
|
|
vs Relative !LocatingPin placement. For example, in an AMV, or any music
|
|
video actually, the positioning of clips should be always relative against
|
|
the audio/music. However, if you are editing a scene in a movie, you want
|
|
the next scene to appear relative to the last scene played. In the first,
|
|
you want to keep the scenes always synced up against the audio, while in the
|
|
latter, you just want the scenes to appear one after another.
|
|
|
|
PercivalTiglao:: '2008-07-16T05:32:45Z'
|
|
|
|
* Yes, indeed, that is what I am planning. The drawing above just doesn't show
|
|
every connection. The interaction between high-level model and rules system
|
|
mostly goes via the ``session defaults'"'', which are facts _and_ rules. Thus,
|
|
in your example, the user would just use the ``default placement'"''. My
|
|
Intention was to use *tags* to quite some extent. The user would be able
|
|
to tag the source footage, and then rules can kick in when a certain tag
|
|
applies. Incidentally, integrating prolog is immediately on the agenda,
|
|
because first we want to flesh out the very basic system and get to work
|
|
basic rendering. Until then, I use a _mock implementation_ of the
|
|
query/rules system, which just returns some hard wired defaults.
|
|
|
|
Ichthyostega:: '2008-09-04T15:38:21Z'
|
|
|
|
|
|
|
|
Conclusion
|
|
----------
|
|
Accepted. The drawing was moved into the GIT tree. +
|
|
It was upgraded and reworked
|
|
https://git.lumiera.org/?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-2.svg;hb=0b9f2e2c3139cad542013caac593cb5972a2e3f6[in 2022]
|
|
|
|
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|