Ichthyostega
25eb6a61e3
- use HTTPS - avoid redirects - supply Archive.org snapshots for old resources
78 lines
3.4 KiB
Text
78 lines
3.4 KiB
Text
Architecure Overview
|
|
====================
|
|
|
|
[grid="all"]
|
|
`------------`-----------------------
|
|
*State* _Final_
|
|
*Date* _2008-03-06_
|
|
*Proposed by* link: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
|
|
link:http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT]^
|
|
|
|
|
|
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 accompaning 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.
|
|
--- link:PercivalTiglao[] [[DateTime(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.
|
|
-- link:Ichthyostega[] [[DateTime(2008-09-04T15:38:21Z)]]
|
|
|
|
|
|
|
|
Conclusion
|
|
----------
|
|
Accepted. The drawing was moved into the GIT tree, hopefully it will be
|
|
maintained in future.
|
|
|
|
|
|
|
|
Back to link:/documentation/devel/rfc.html[Lumiera Design Process overview]
|