Ichthyostega
7d237647d4
In the past we allowed a lot of leeway when referring to our web-interface to the Lumiera Git repositories (git.lumiera.org/gitweb) Unfortunately this caused the AI scraper bots »out there« to capture millions of URLs for all the different flavours of spelling them out. And now they haunt our website and try to scrap that content again and again; even while we effectively prevent that kind of abuse, rejecting those ongoing attempts at content-scraping causes a dangerously high amount of traffic. With this changeset, all cross references in the documentation section are rewritten to the only remaining valid form of that Gitweb URL.
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/gitweb?p=LUMIERA;a=blob_plain;f=doc/devel/draw/Lumi.Architecture-1.svg;hb=HEAD[maintained in GIT(2008)]·
|
|
https://git.lumiera.org/gitweb?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/gitweb?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]
|