091785c2d4
This reverts commit 65bae31de4103abb7d7b6fd004a8315973d3144a. and reprocessed the wrapping. Note that the automatic wrapping is not perfect, some manual fixing by removing some hunks was required.
78 lines
3.3 KiB
Text
78 lines
3.3 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.
|
|
|
|
See the SVG drawing
|
|
http://www.lumiera.org/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Archi
|
|
ecture-1.svg;hb=HEAD[Overview of Lumiera Architecture)] maintained in GIT
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
* the Application has three Layers: 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 Backend
|
|
* all media object manipulation, deciding and configuration is the Proc
|
|
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 http://telniratha.atspace.com/ui_architecture.jpg[some
|
|
drafts] for the ui. Here is the
|
|
http://telniratha.atspace.com/ui_architecture.odg[oodraw document]. 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:Lumiera/DesignProcess[]
|