clean-up: re-classify essential RfCs
The RfC documents were written to complement discussions of the Lumiera developers; yet since the time where ''Ichthyo'' is working basically alone on the project, this kind of discussions have ceased. During the following years, some ideas promoted by the existing RfC documents became rather detached from the actual state of development in the code base. Many of the existing RfC documents require some commentary to place them into context, and some of the decisions taken in the early stage of the project should be **re-assessed**. This includes the decision to reject some proposals, which initially might have seemed desirable, yet could not be reconciled with the understanding of the matter and topic in question, as was gained through the ongoing analysis and development.
This commit is contained in:
parent
c7528bbe8a
commit
051cb31e28
32 changed files with 1266 additions and 131 deletions
|
|
@ -1,7 +1,7 @@
|
|||
External Tree Description
|
||||
=========================
|
||||
:Author: Ichthyostega
|
||||
:Date: Fall 2015
|
||||
:Date: Autumn 2015
|
||||
|
||||
|
||||
|
||||
|
|
@ -17,11 +17,11 @@ Any collaboration requires, as an underlying, some kind of common understanding.
|
|||
And any formalised, mechanical collaboration requires to represent that common point of attachment --
|
||||
at least as _symbolic representation._ The »External Tree Description« is shaped to fulfil this need:
|
||||
_in theory,_ the whole field could be represented, symbolically, as a network of hierarchically
|
||||
structured elements. Yet, _in practice,_ all we need is to conceive the presence of such a representation,
|
||||
structured elements. Yet, _in practice,_ all we need is to presuppose the presence of such a representation,
|
||||
as a backdrop to work against. And we do so -- we work against that symbolic representation,
|
||||
by describing *changes* made to the structure and its elements. Thus, the description of changes,
|
||||
the link:{ldoc}/technical/library/DiffFramework.html[diff language], refers to and partially embodies
|
||||
such symbolically represented elements and relations.
|
||||
by describing *changes* made to the structure and its elements. And so the description of changes,
|
||||
the link:{ldoc}/technical/library/DiffFramework.html[diff language], thus refers to and partially
|
||||
embodies such symbolically represented elements and relations.
|
||||
|
||||
Elements, Nodes and Records
|
||||
---------------------------
|
||||
|
|
@ -29,7 +29,7 @@ We have to deal with _entities and relationships._
|
|||
Entities are considered the building blocks, the elements, which are related by directional links.
|
||||
Within the symbolic representation, elements are conceived as *generic nodes* (`GenNode`),
|
||||
while the directed relations are impersonated as being attached or rooted at the originating side,
|
||||
so the target of a relation has no traces or knowledge of being part of that relation. Moreover, each
|
||||
so that the target of a relation has no knowledge of being part of that relation. Moreover, each
|
||||
of our nodes bears a _relatively clear-cut identity._ That is to say, within the relevant scope in question,
|
||||
this identity is unique. Together, these are the building blocks to represent any *graph*.
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ One point in the agenda of future meetings will be to work through proposals in
|
|||
|
||||
The development model
|
||||
---------------------
|
||||
We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course)._ Cehteh_ is currently working on a Git web frontend which makes the codebase in the mob-repo web-editable like a wiki.
|
||||
We employ a distributed model based on Git. We want this repository to be as complete as possible, including documentation in embedded TiddlyWikis and Bug reports. Each dev has its own GIT repo, devs are pulling from each other, they are free to cherry pick and try to make the combined version work. Point is that everyone can clone the git, negotiate with the others what s(he) wants to do, and hack on. Every dev signs off his branch with an standardized signature. For small changes we provide a ``Mob GIT'', i.e. _anonymously pushable Git_ (which is untrusted of course). _Cehteh_ is currently working on a Git web frontend (``webgit'') which makes the codebase in the mob-repo web-editable like a wiki.
|
||||
|
||||
Will we need a stable version or an official branch? not yet -- as long as the team is small it will work more painless without. At some point, when the project is more mature, we will define an official branch. Later on we will have automated builds and regression test runs. As we do test-driven development anyways, it's just a question of someone setting up all the infrastructure, then we'll do it.
|
||||
|
||||
|
|
|
|||
|
|
@ -65,9 +65,8 @@ in registering to the project in planning/alpha stage to interest people such as
|
|||
It was noted that the
|
||||
https://web.archive.org/web/20090601174640/http://www.linux.com/archive/feature/126441[article on Linux.com]
|
||||
resulted in a lot of people contacting Ichthyo and Cehteh.
|
||||
»I believe in Cinelerra«
|
||||
https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-January/012806.html[»I believe in Cinelerra«]
|
||||
by Leo Germani also generated a lot of traffic by developers.
|
||||
[purple]#<lost content at `http://plot.bek.no/pipermail/piksel/2008-January/003328.html`>#
|
||||
Some level of presence on mailing lists would be good although not too much just enough to indicate the project is going on.
|
||||
|
||||
Conclusion: volunteer needed to coordinate publicity (not overly urgent, but helpful)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Idea: Design the Render Nodes interface
|
|||
link:{rfc}/DesignRenderNodesInterface.html[RfC / Call for a Render Node interface]
|
||||
|
||||
_Cehteh_ points out that, as we are in the pre-alpha phase, interfaces may be growing on-demand.
|
||||
Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimenta'' tag,
|
||||
Later on, interface versions will be numbered. If needed, we could add a special ``draft'' or ``experimental'' tag,
|
||||
or, alternatively, use the common numbering scheme, where odd major version numbers denote the development line of an interface.
|
||||
|
||||
_Ichthyo_ agrees, but adds he also meant ``interface'' in this proposal in a wider sense,
|
||||
|
|
|
|||
|
|
@ -175,7 +175,7 @@ ct:: '2007-07-11 13:10:07'
|
|||
|
||||
.State -> Dropped
|
||||
Development took another direction over the course of the years;
|
||||
Lumiera is not based on a _generic plug-in Architecture_ and the topic
|
||||
Lumiera is _not_ based on a _generic plug-in Architecture_ and the topic
|
||||
of interfaces for _dedicated plugins_ still needs to be worked out
|
||||
|
||||
Ichthyostega:: '2023-10-24 22:55:23'
|
||||
|
|
|
|||
|
|
@ -149,12 +149,15 @@ an architecture based on abstractions and exploiting the proven design
|
|||
patterns.
|
||||
|
||||
Ichthyo:: '2008-11'
|
||||
|
||||
+
|
||||
--
|
||||
It has that flexibility, yes. But that means not that we have to abuse it in
|
||||
any way. The main() there and thus the bootstrap of the application is under
|
||||
any way. The `main()` there and thus the bootstrap of the application is under
|
||||
our tight control, if we want to reject scriptable/highly configurable
|
||||
bootstrapping there then we can just do so. Thats more a social than a
|
||||
technical decision. I personally don't like if a design is ``nannying'' and puts
|
||||
technical decision.
|
||||
|
||||
I personally don't like if a design is ``nannying'' and puts
|
||||
too much constraints into unforeseen areas. If the computer can do some task
|
||||
better than we, it shall do it. This still means that I want to stay very much
|
||||
in control, it should only do some tedious, error-prone managing tasks for me.
|
||||
|
|
@ -167,6 +170,7 @@ we have no control over. But I now realized that we can nicely use that for our
|
|||
own internal things too. IMO thats some very valuable service.
|
||||
|
||||
ct:: '2008-11-08T06:26:18Z'
|
||||
--
|
||||
|
||||
Some further minor details: We didn't finish the discussion about namespaces on
|
||||
the last meeting. (I know I still have to write up a proposal showing the two
|
||||
|
|
@ -202,5 +206,24 @@ to document this here 😛
|
|||
|
||||
ct:: '2009-02-03T17:28:28Z'
|
||||
|
||||
|
||||
💡 +
|
||||
[underline]#Historical remark#: this RfC is related to a series of discussions
|
||||
and controversies during the early stages of the project -- which eventually
|
||||
helped to establish a style of internal organisation within the application.
|
||||
|
||||
After exploring various angles, Lumiera eventually became a *modularised Monolith*
|
||||
-- using plug-ins for strictly optional parts of the system. Notably, the GUI
|
||||
is loaded as a plug-in, and the integration with specific media-handling libraries
|
||||
will rely on plug-in components as well. On the other hand, the core comprises
|
||||
a small selection of built-in »Subsystems«, which are started with a formalised
|
||||
lifecycle and dependency management. Flexibility is not attained by allowing
|
||||
to totally reconfigure the application structure -- rather we allow for an
|
||||
unusual degree of flexibility by combination and reconfiguration of
|
||||
behaviour patterns within the application.
|
||||
|
||||
Ichthyotega:: '2025-09-20'
|
||||
|
||||
|
||||
''''
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Config Loader
|
|||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Parked_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2008-08-07_
|
||||
|*Proposed by* | **ct**
|
||||
|====================================
|
||||
|
|
@ -44,8 +44,8 @@ NOTE: (by _Ichthyostega,_ 2023) +
|
|||
|
||||
|
||||
|
||||
Parked
|
||||
~~~~~~
|
||||
|
||||
.State -> Parked
|
||||
While the general idea seams adequate, the topic of Configuration
|
||||
requires a much more in-depth Requirement Analysis. Moreover, considering
|
||||
the state of tooling today (2023), I consider it questionable still to rely
|
||||
|
|
@ -64,13 +64,35 @@ to be addressed _after achieving the first integration_ of the Engine.
|
|||
Ichthyostega:: '2023-10-24' ~<prg@ichthyostega.de>~
|
||||
|
||||
|
||||
.State -> Dropped
|
||||
Lumiera needs a system for configuration, but it will not work as proposed here.
|
||||
The reasons for this decision can be traced back to questions of architecture
|
||||
and the intended use of ``Configuration''. This became first clear in a
|
||||
discussion between _Cehteh_ and _Ichthyo_, as they were walking together
|
||||
through the forest north of the Karlsruhe castle in August 2011.
|
||||
|
||||
//Conclusion
|
||||
//----------
|
||||
//conclusion: When approved (this proposal becomes a Final)
|
||||
// write some conclusions about its process:
|
||||
While _Cehteh_ aims at an unified set of configuration data, composed by
|
||||
layering system-, user- and further local configuration files, to be combined
|
||||
with textual expansion- and replacement mechanisms -- and the ability to
|
||||
target a wide array of ``settings'' within the application, the intentions
|
||||
of _Ichthyo_ go into an almost antithetical direction: He rather wants
|
||||
to split off a very limited set of ``parametrisation'' and ``installation
|
||||
configuration'', while handling most of the other possible choices by evaluation
|
||||
of _configuration rules,_ which are tightly interwoven with the Session and
|
||||
are actively resolved in the Builder, as opposed to being provided by a global
|
||||
static _configuration service._ With this model, configuration can be injected
|
||||
from various sources as a structured set of _facts._ Furthermore, _Ichthyo_
|
||||
wants to isolate the behaviour of the application from ad-hoc tweaks through
|
||||
textual replacements and environment variables, rather looking for ways to
|
||||
record any application of rules or facts in the global _Event Log._
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
....
|
||||
|
||||
|
||||
....
|
||||
|
||||
~What follows below is extended documentation for _Cehteh_'s Config System proposal...~
|
||||
|
||||
''''''''''''''''
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Design Process : Data Backend
|
|||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Parked_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2007-06-04_
|
||||
|*Proposed by* | ct
|
||||
|====================================
|
||||
|
|
@ -37,8 +37,8 @@ This just starts as braindump, I will refine it soon:
|
|||
link:http://localhost:8888/project/background/history/PossibilitiesAtHand.html[things possible in the middle layer]...
|
||||
|
||||
|
||||
Parked
|
||||
~~~~~~
|
||||
Conclusion: Dropped
|
||||
-------------------
|
||||
The underlying principles remain valid, yet development took another
|
||||
direction during the last years. Special frameworks for high-performance
|
||||
asynchronous IO will be used for dedicated use cases. A garbage collector
|
||||
|
|
@ -61,11 +61,56 @@ Developement takes place in the repo now
|
|||
|
||||
ct:: '2007-06-27T16:14:56Z'
|
||||
|
||||
.State -> Parked
|
||||
Development took another direction over the last years;
|
||||
the former »Backend« layer is called »Vault« now and structured differently.
|
||||
|
||||
Ichthyostega:: '2023-10-24T22:45:55Z'
|
||||
|
||||
|
||||
.State -> Dropped
|
||||
The approach to most of the topics listed in this RfC has shifted, and thus
|
||||
it is time to draw the conclusion that overall Lumiera will not use a »Backend«
|
||||
as an _adaptation layer,_ in the way envisioned here. Notably the idea of
|
||||
centralising _any access to resources_ to apply some kind of instrumentation
|
||||
and regulation is rejected. Rather, the »Vault« (as it is called now),
|
||||
provides specialised low-level services with deep vertical integration;
|
||||
this implies rather to establish dedicated control circuits for a small
|
||||
number of special resources deemed performance critical.
|
||||
|
||||
Most topics touched by this RfC however remain relevant,
|
||||
yet will be approached differently...
|
||||
|
||||
- while non-blocking, asynchronous I/O is still considered essential,
|
||||
it is acknowledged that getting a grip at the resource usage of
|
||||
external libraries and frameworks, integrated via plug-in, is a
|
||||
non-trivial task, and must be approached at a case-by-case base.
|
||||
|
||||
- the Scheduler provides a much more high-level and specialised
|
||||
execution service then intended initially; the majority of
|
||||
resource usage regulation will be achieved by adjusting the
|
||||
job generation, which is connected to high-level structures,
|
||||
while relying on generic resource observation facilities
|
||||
in the Vault.
|
||||
|
||||
- the Cache service will require a deep integration with the Builder
|
||||
and the media / asset management; _cache invalidation_ will be
|
||||
based on a _naming and identification scheme,_ which requires
|
||||
explicit support by the high-level metadata management.
|
||||
|
||||
- the Vault has no connection to media processing whatsoever,
|
||||
it does not decode / encode data or mark and map parts of
|
||||
media streams; this topic is coordinated at the level of
|
||||
the builder and delegated to external facilities, while
|
||||
the Vault provides some dedicated resource management
|
||||
(notably handling GPU access and shader code)
|
||||
|
||||
- file handles and generic file access are considered a non-issue,
|
||||
as is the occasional usage of multithreading -- as long as any
|
||||
substantial parallelism is organised through the scheduler.
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
|
||||
''''
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ The Lumiera (developer) documentation shall be organised in the following way:
|
|||
link:{ldoc}/user/intro/intro.html[Lumiera from Outer Space],
|
||||
which outlines our vision and the fundamental concepts.
|
||||
. there is a section holding our link:{ldoc}/design/[design documents].
|
||||
Deliberately, these are written so to omit any technicalities,
|
||||
Deliberately, these are written in a way omitting any technicalities,
|
||||
which keeps them valid as the technology evolves.
|
||||
. the entrance to the technical documentation is formed by
|
||||
link:{ldoc}/technical/overview.html[The inner Core] document.
|
||||
|
|
@ -132,8 +132,8 @@ redundancies could be removed, as result from that discussion. _Ichthyo_ then ed
|
|||
and extended the original RfC to reflect the existing structure.
|
||||
|
||||
A serious problem is posed by the rather tedious procedure to define cross-links in the
|
||||
Asciidoc based web content. link:WebsiteSupportMarkup.html[Another RfC] was created to
|
||||
discuss these problems in detail, leading to a solution proposal, which unfortunately
|
||||
Asciidoc based web content. link:{rfc}/WebsiteSupportMarkup.html[Another RfC] was created
|
||||
to discuss these problems in detail, leading to a solution proposal, which unfortunately
|
||||
was never implemented (due to lack of developer capacity). This _somehow transitory_
|
||||
situation had the (adverse) effect that most detailed technical content was authored
|
||||
within the Development TiddlyWiki.
|
||||
|
|
@ -153,12 +153,12 @@ Comments
|
|||
which includes the documentation. Why should we overthrow these results now and
|
||||
re-start the discussion? Lets just stick to this agreed on structure!
|
||||
* especially I don't like the way this proposal tries to squeeze everything into
|
||||
an completely uniform structure. It is simply not true that the RFCs are just the
|
||||
a completely uniform structure. It is simply not true that the RFCs are just the
|
||||
second level, and doxygen would cover the 3^rd^ level. Look at the existing
|
||||
documentation to see why.
|
||||
- RFCs are a 'kind' of document, not a 'hierarchy level.' Indeed, our existing
|
||||
- RFCs are a `kind' of document, not a `hierarchy level'. Indeed, our existing
|
||||
RFCs span all three hierarchy levels, and this is OK so and should remain this
|
||||
way. (And yes, I like the RFCs much and want to retain them)
|
||||
way. (And, in fact I consider the RFCs relevant and want to retain this formalism)
|
||||
- RFCs are well suited to topics requiring discussion and agreement by the whole
|
||||
core developer team. I see no point in 'pseudo-RFC-ing' the individual design
|
||||
decisions only relevant for an isolated part of the application and without
|
||||
|
|
@ -170,11 +170,11 @@ Comments
|
|||
when asciidocing the content).
|
||||
* so my conclusion is rather having one overview text, and then the split into
|
||||
*conceptual* and *technical* documentation, each of which has a separate sub
|
||||
structure not necessarily congruent to the structure on the other half. RFCs,
|
||||
structure not necessarily congruent to the structure at the other half. RFCs,
|
||||
UML model and doxygen are just separate and consistent bodies of documentation
|
||||
and can be referred to from the main documentation. (I agree with the observation
|
||||
regarding permanent links into doxygen. But I can't imagine there isn't some
|
||||
existing solution to this problem)
|
||||
existing solution to this problem, waiting to be discovered)
|
||||
|
||||
Ichthyostega:: '2010-10-15' ~<prg@ichthyostega.de>~
|
||||
|
||||
|
|
@ -190,7 +190,7 @@ Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~<prg@ichthyostega.de>~
|
|||
|
||||
|
||||
.State -> Final
|
||||
I am using this structure now since several years, without encountering any
|
||||
I am using this structure since several years now, without encountering any
|
||||
serious mismatch or incompatibility. The situation with the cross-linking
|
||||
generator, which still remains to be implemented, is obviously some kind
|
||||
of impediment, since it prevents me from migrating more mature content
|
||||
|
|
@ -199,8 +199,10 @@ from the TiddlyWiki into the documentation section of the website.
|
|||
Furthermore, I should notice, as a limitation, that I am the _only one_ to
|
||||
use this structure actively -- so the fact that I feel comfortable with
|
||||
the arrangement should be taken with a grain of salt. Yet, on the other
|
||||
hand, we have meanwhile a massive body of information integrated
|
||||
into this structure, so that it can be considered more than
|
||||
hand, we have meanwhile a massive body of information structured
|
||||
this way, so that it can be considered more than
|
||||
just a ``proposal for discussion''
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
//endof_comments:
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Design Process : Development Framework
|
|||
|====================================
|
||||
|*State* | _Final_
|
||||
|*Date* | _2007-06-08_
|
||||
|*Proposed by* | ct
|
||||
|*Proposed by* | Cehteh
|
||||
|====================================
|
||||
|
||||
|
||||
|
|
@ -36,12 +36,12 @@ Description
|
|||
|
||||
Tasks
|
||||
^^^^^
|
||||
* cehteh will setup a initial repository
|
||||
* _Cehteh_ will setup a initial repository
|
||||
(see -> link:{rfc}/RepositorySetup.html[RfC: proposed repository structure])
|
||||
* ichthyo has setup a debian-APT-depot at 'deb/ichthyostega.de' and will
|
||||
add backport packages there if necessary so the debian-people can stay near
|
||||
Etch/stable in the next time
|
||||
* ichthyo volunteers to get the new source into a debian package structure from
|
||||
* _Ichthyo_ volunteers to get the new source into a debian package structure from
|
||||
start (same as the current cinelerra is)
|
||||
|
||||
.And for later:
|
||||
|
|
@ -133,5 +133,56 @@ We have now a ``compatibility wiki'', finalized this proposal
|
|||
|
||||
ct:: '2008-03-26T13:43:26Z'
|
||||
|
||||
''''
|
||||
....
|
||||
|
||||
|
||||
|
||||
....
|
||||
|
||||
Assessment 2025
|
||||
~~~~~~~~~~~~~~~
|
||||
[underline]#In hindsight,# this RfC captures the baseline of our project setup. +
|
||||
We soon settled upon the following toolchain, which is used up to today:
|
||||
|
||||
- One published Git repository per developer, with direct pull / merging; +
|
||||
history is consolidated eventually into the
|
||||
link:{rfc}/MasterRepositorySetup.html#historical_remark[»official Lumiera repository«],
|
||||
which is made accessible at
|
||||
https://git.lumiera.org/?p=LUMIERA;a=summary[`git://git.lumiera.org/LUMIERA`]
|
||||
- We never used link:{rfc}/GitSubmoduleTransistion.html#_comments[Git submodules]...
|
||||
- https://www.scons.org/[SCons] became the primary buildsystem soon,
|
||||
with Autotools discontinued in 2011
|
||||
- https://trac.edgewall.org/[Trac] is used as planning- and ticket system.
|
||||
- API documentation is extracted with https://www.doxygen.nl/[Doxygen]
|
||||
- Website and documentation pages are generated by
|
||||
https://asciidoc-py.github.io/[Asciidoc], with source files for
|
||||
documentation maintained
|
||||
https://git.lumiera.org/?p=LUMIERA;a=blob;f=doc/index.txt;h=9bc0f11e6fb67588388e7616320b695841571278;hb=20f3252892d5b53a05ecd8aeb571122806baba17[in-tree],
|
||||
published
|
||||
https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[automatically on push].
|
||||
- A https://classic.tiddlywiki.com/[TiddlyWiki] is used for development notes
|
||||
- for Unit-Tests, we use our own minimalist
|
||||
https://git.lumiera.org/?p=LUMIERA;a=blob;f=src/lib/test/run.hpp;h=035633af9bde7a8053bcd304baffc21693dcf031;hb=20f3252892d5b53a05ecd8aeb571122806baba17[Test-runner].
|
||||
and a
|
||||
https://git.lumiera.org/?p=LUMIERA;a=blob;f=tests/test.sh;h=8c13810eb475bbacd97c528607e6750f47bb145e;hb=20f3252892d5b53a05ecd8aeb571122806baba17[shell script]
|
||||
to support definition of test collections.
|
||||
- A Debian package is maintained with
|
||||
https://wiki.debian.org/PackagingWithGit[git-buildpackage] and published
|
||||
in our own DEB depot generated by the
|
||||
https://wiki.debian.org/DebianRepository/SetupWithReprepro[reprepro tooling].
|
||||
- UML plays only a marginal role today -- yet in fact we generated our initial class
|
||||
hierarchy with https://web.archive.org/web/20070625100128/http://bouml.free.fr/[Bouml],
|
||||
as proposed by _Cehteh_. Sometimes, UML design sketches are made with
|
||||
https://uml.sourceforge.io/[Umbrello], while schematic drawings,
|
||||
Icons and graphic elements for the GUI are maintained
|
||||
with https://inkscape.org/[Inkscape]
|
||||
- Test-visualisation relies heavily on
|
||||
https://graphviz.org/[Graphviz] and
|
||||
http://www.gnuplot.info/[Gnuplot]
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
|
||||
''''
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Design Process : Distributed Development Framework
|
|||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Final_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2007-06-07_
|
||||
|*Proposed by* | ct
|
||||
|====================================
|
||||
|
|
@ -47,9 +47,18 @@ Made this `final', this proposal got accepted and is already in use without
|
|||
much discussion
|
||||
|
||||
ct:: '2007-06-27T16:07:13Z'
|
||||
....
|
||||
|
||||
|
||||
|
||||
....
|
||||
[large]#🌑 🌒 🌓 🌔 🌕 🌖 🌗 🌘 🌑#
|
||||
|
||||
[underline]#Historical remark#: Not sure what this RfC was meant to propose; +
|
||||
During the next year, an ambitious side-project named »*uwiki*« was started,
|
||||
[underline]#Historical remark#: This was ultimately the first
|
||||
_conceptual_ (not process-related) RfC published in this Design-Process
|
||||
(note the date!). Thus, _in hindsight,_
|
||||
the question arises what this RfC was meant to propose; +
|
||||
During the following months, an ambitious side-project named »**uWiki**« was started,
|
||||
with the goal to provide a wiki-like web frontend based on completely self-contained
|
||||
storage in a Git repository, without requiring any kind of data base. This project,
|
||||
however -- in spite of some compelling prototype implementations -- was abandoned;
|
||||
|
|
@ -58,12 +67,40 @@ minimalist setup and would require a significant amount of web development
|
|||
rather -- a task no one was willing to take on.
|
||||
|
||||
Yet the Lumiera project succeeded in building a web presence based on
|
||||
https://asciidoc-py.github.io/[Asciidoc] sources checked into Git, with a lightweight
|
||||
commit-hook script to automatically publish any changes on git-push -- a scheme
|
||||
https://asciidoc-py.github.io/[Asciidoc] sources
|
||||
https://git.lumiera.org/?p=website;a=summary[checked into Git],
|
||||
with a lightweight
|
||||
https://git.lumiera.org/?p=website;a=blob;f=build_website.sh;h=60b90e18d5732d66566baf2c20a217212a5dcece;hb=aefc91e13a95a3c742dc8143c374ec982e0aa56b[commit-hook script]
|
||||
to automatically publish any changes on git-push -- a scheme
|
||||
which comes close to the gist of this RfC.
|
||||
|
||||
Ichthyo:: '2025-09-08'
|
||||
Ichthyostega:: '2025-09-08'
|
||||
|
||||
|
||||
.State -> Dropped
|
||||
After reconsidering this RfC, _many years later,_ it seems prudent to mark it as __`Dropped'.__
|
||||
The reasons for this decision are manifold. For one, the project never fully embraced this
|
||||
working style, it was a vision from the early days rather. _Parts_ of that vision became a
|
||||
practical reality, like the use of a link:{rfc}/MasterRepositorySetup.html[shared master repository],
|
||||
or the use of Git and Asciidoc to generate and publish our website directly from a hook-script.
|
||||
|
||||
But we did not ``create our own toolset to track issues, tasks, bugs in a distributed manner''.
|
||||
This idea might seem enticing for a new experimental project, and, when taken further, it leads to
|
||||
a development style where most questions of coordination, and notably the preparation of releases
|
||||
and the delivery and roll-out of published code are handled by an automated production line.
|
||||
Developers can do what they like most: ``code cool things'' -- while all that
|
||||
``nasty other stuff'' is dealt with by an »Invisible Hand«.
|
||||
|
||||
I do not consider such a setup healthy on the long run, nor can I see how it would be
|
||||
adequate for a project with liabilities to care for: we should not consider the coordination
|
||||
of a release cycle as something extraneous, to be ``automated away'' -- it requires the
|
||||
full attention of the developers rather, to provide a longtime stable version and not to
|
||||
interfere with the work of creative people, using the software in novel ways,
|
||||
not foreseeable by the developers.
|
||||
For this reason, I moved into the opposite direction and have now switched to the
|
||||
link:/project/background/GitFlow.html[Git-flow branching model].
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
''''
|
||||
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -204,7 +204,7 @@ be introduced prematurely:
|
|||
|
||||
- Git bisect is an essential tool when working with a code base which you
|
||||
do not understand. With a well-crafted yet ambitious system the situation
|
||||
is quite distinct: in such a system, the change which caused the breakage
|
||||
is quite different: in such a system, the change which caused the breakage
|
||||
is obvious and easy to spot -- while the actual challenge is to
|
||||
understand _why_ difficulties arose -- not to mention the amount
|
||||
of work required to develop a path of escape from a real dilemma.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,10 @@
|
|||
Design Process : Submodules
|
||||
===========================
|
||||
|
||||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Parked_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2008-04-09_
|
||||
|*Proposed by* | ct
|
||||
|====================================
|
||||
|
|
@ -55,8 +59,8 @@ Pros
|
|||
|
||||
Cons
|
||||
^^^^
|
||||
* needs some more git-fu to be used by the developers
|
||||
* we will host considerably more git repositories (bigger list in gitweb),
|
||||
* needs some more Git-fu to be used by the developers
|
||||
* we will host considerably more Git repositories (bigger list in gitweb),
|
||||
this is not a problem but might look more confusing
|
||||
|
||||
|
||||
|
|
@ -75,16 +79,36 @@ When all people get used to it it allows a cleaner more sane work flow and well
|
|||
isolated, less conflicting commits.
|
||||
|
||||
|
||||
|
||||
Conclusion: Dropped
|
||||
-------------------
|
||||
The extended usage of Git Submodules for parts of the code base is not desirable.
|
||||
|
||||
|
||||
Comments
|
||||
--------
|
||||
|
||||
.State -> Parked
|
||||
We concluded that that submodules are not yet needed with exception for the
|
||||
./doc folder. Parked for now.
|
||||
|
||||
ct:: '2008-07-26 09:09:57'
|
||||
|
||||
|
||||
.State -> Dropped
|
||||
Git Submodules were a highly anticipated feature at the time when the
|
||||
Lumiera project started -- yet the actual implementation was generally
|
||||
perceived as a disappointment, since the tooling failed to provide that
|
||||
kind of seamless integration into everyday Git usage as was desirable.
|
||||
|
||||
There remains one area however, where the Lumiera project might revisit
|
||||
the idea of using Submodules: our _Website_ -- which might become a portal
|
||||
to integrate several rather loosely coupled efforts eventually, notably
|
||||
the public front-end, including some images, a user documentation section,
|
||||
the technical documentation and possibly a knowledge base maintained
|
||||
separately.
|
||||
|
||||
Ichthyostega:: '2025-09-25'
|
||||
|
||||
|
||||
''''
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ there too, so it gets issued automatically.
|
|||
probably after parsing the commandline in main (and either this or the
|
||||
loading of a existing session will bring the proc layer up into fully
|
||||
operational state +
|
||||
Ichthyo:: 'DateTime(2008-04-09T02:13:02Z'
|
||||
Ichthyo:: '2008-04-09T02:13:02Z'
|
||||
|
||||
* About NoBug initialization: I've seen that you made a `nobugcfg` where
|
||||
you centralized all nobug setup. Problem here is that a change in that file
|
||||
|
|
@ -199,7 +199,7 @@ Some comments...
|
|||
- Regarding organisation of includes:... agreed
|
||||
- Initialisation of the very...
|
||||
|
||||
* I won't hesitate to add some C\++ functionality to give *NoBug* an
|
||||
* I won't hesitate to add some C\++ functionality to give *NoBug* a
|
||||
singleton initialization in C++
|
||||
|
||||
- Then there is the initialisation of common services... _agreed_
|
||||
|
|
@ -266,7 +266,7 @@ outdated and ``misaligned'' IMHO.
|
|||
* Startup and Shutdown of an application like Lumiera requires way more
|
||||
than this. More specifically, we have to consider modularisation.
|
||||
* in hindsight, I was naiive to agree with this proposal.
|
||||
It can not be that easy.
|
||||
_It can not be that easy._
|
||||
* my comments do indeed indicate the direction the further development
|
||||
did take: today, Lumiera does the _exact opposite_ of this proposal,
|
||||
there is *no central init call* -- we use *modularised hooks* instead
|
||||
|
|
@ -280,6 +280,18 @@ we should preferably start a new RfC.
|
|||
Ichthyostega:: 'Mo 08 Sep 2014 01:44:49 CEST' ~<prg@ichthyostega.de>~
|
||||
|
||||
|
||||
💡 +
|
||||
[underline]#Historical remark#: This RfC is closely related to discussions
|
||||
regarding the link:{rfc}/ApplicationStructure.html[Application Structure]
|
||||
and possibly using a link:{rfc}/AllPluginInterfacesAreC.html#_conclusion[Plug-in based Achitecture].
|
||||
|
||||
Investigating and debating these possibilities in a productive way was key
|
||||
to gain an understanding what is required to build and maintain an Application
|
||||
of this dimension and scope.
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
|
||||
//endof_comments:
|
||||
|
||||
''''
|
||||
|
|
|
|||
|
|
@ -143,5 +143,20 @@ this interfaces we will *break this plugin* intentionally!
|
|||
|
||||
ct:: '2008-10-24T03:43:43Z'
|
||||
|
||||
|
||||
Clarification of relevance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
As this RfC touches on the subject of Plug-ins, it should be stated very clearly
|
||||
that Lumiera is **not based on a »Plugin Architecture«**. This Architecture Style
|
||||
was indeed link:{rfc}/AllPluginInterfacesAreC.html[proposed and considered] during
|
||||
the early stages of the project, but rejected later, based on the ensuing discussion
|
||||
and experience with existing systems, as well as with our own implementation drafts
|
||||
going into this direction.
|
||||
|
||||
Lumiera will use Plug-ins however, to add _optional capabilities._
|
||||
And thus everything stated in this RfC regarding unique identifiers remains valid.
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
''''
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
|
|
|||
|
|
@ -111,10 +111,10 @@ project.
|
|||
|
||||
Comments
|
||||
--------
|
||||
[underline]#This document is one of the **first RfC**s# published in *Summer 2007*, +
|
||||
[underline]#This document is among the **earliest RfC**s# published in *Summer 2007*, +
|
||||
as a new community movement was about to form, with the goal to improve Cinelerra
|
||||
for real, in a new version Cinelerra-3.
|
||||
Early in 2008, this initiative had turned into a new project, with the
|
||||
At the beginning of 2008, this initiative had turned into a new project, with the
|
||||
https://web.archive.org/web/20231026200633/https://lists.cinelerra-cv.org/pipermail/cinelerra-skolelinux/2008-March/013474.html[community chosen]
|
||||
name »*Lumiera*« -- years later, in 2010, documentation and existing RfC entries
|
||||
were migrated from _Cehteh_'s `pipapo.org` Wiki to the
|
||||
|
|
|
|||
|
|
@ -51,6 +51,7 @@ ct:: '2008-04-08T21:48:51Z'
|
|||
|
||||
''''
|
||||
|
||||
[[historical_remark]]
|
||||
[underline]#Historical remark#: This RfC describes the setup we used up to ~2012. +
|
||||
After that point, I was working alone basically (not counting occasional small contributions),
|
||||
and consequently the current state could be found in the ``ichthyo'' Git repository
|
||||
|
|
|
|||
|
|
@ -1,3 +1,7 @@
|
|||
Design Process : Optimiser
|
||||
==========================
|
||||
|
||||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Parked_
|
||||
|
|
@ -55,13 +59,36 @@ The good news is, that:
|
|||
always work in both colorspaces directly
|
||||
|
||||
|
||||
Parked
|
||||
~~~~~~
|
||||
|
||||
.State -> Parked
|
||||
Generally this is accepted but needs some more polishing when we go over it.
|
||||
|
||||
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
|
||||
|
||||
|
||||
.Reassessment : remains valid
|
||||
[underline]#Relevance confirmed 2025.#
|
||||
This RfC is written narrow enough to just define the goal of an optimised
|
||||
render pipeline -- which _was_ and _is_ a central goal of the Lumiera project.
|
||||
|
||||
Approaching this topic however _requires much more work_ and notably a detailed
|
||||
analysis of the possibilities, based on *facts and measurements*. There is the
|
||||
real danger to get attached to some implementation idea deemed enticing,
|
||||
leading to very specific tweaks which limit the ability to adapt to
|
||||
other relevant requirements.
|
||||
|
||||
Furthermore, since Lumiera aims at being library / framework agnostic,
|
||||
a significant difficulty to overcome first is the build-up of an abstract
|
||||
framework to describe and engage viable optimisations, which can then be
|
||||
applied as transformations within the Builder -- quite similar to the
|
||||
proceedings of an optimising compiler. The description of possible
|
||||
optimisations likely involves elements of knowledge representation,
|
||||
combined with heuristical aspects, possibly augmented by
|
||||
machine learing.
|
||||
|
||||
To summarise: this is a *long-term vision*.
|
||||
|
||||
Ichthyostega:: '2025-09-20'
|
||||
|
||||
|
||||
''''
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ Design Process : Scripting Language
|
|||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Pending_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2008-07-26_
|
||||
|*Proposed by* | ct
|
||||
|====================================
|
||||
|
|
@ -201,9 +201,10 @@ Ichthyostega:: '2023-02-04' ~<prg@ichthyostega.de>~
|
|||
|
||||
Conclusion
|
||||
----------
|
||||
Lua was _accepted_ as the required scripting language by October.2008 dev
|
||||
meeting. However, Ichthyo _questions and overrules_ this decision in Feb.2023
|
||||
and moves this proposal back into the inception stage.
|
||||
Lua was _accepted_ as the required scripting language by the
|
||||
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_lua_scripting_language[Oct.2008 dev meeting].
|
||||
However, Ichthyo __questions and overrules__ this decision in Feb.2023
|
||||
and moves this topic back into the inception stage.
|
||||
|
||||
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Offering Skills for Help
|
|||
|
||||
[options="autowidth"]
|
||||
|====================================
|
||||
|*State* | _Parked_
|
||||
|*State* | _Dropped_
|
||||
|*Date* | _2007-06-13_
|
||||
|*Proposed by* | ct
|
||||
|====================================
|
||||
|
|
@ -90,7 +90,7 @@ it was discussed shortly and deemed ``...only useful if there are more developer
|
|||
|
||||
Reading this RfC today gives me some kind of peculiar melancholic feeling -- it has the vibes of »zero hour«,
|
||||
when all hands on deck are needed and everyone wants to help; people write their names on a blackboard
|
||||
at the wayside, to get into contact, organise themselves or just to find their beloved ones...
|
||||
at the wayside, to get into contact, organise themselves or maybe just to find their beloved ones...
|
||||
|
||||
Ichthyostega:: '2025-09-11'
|
||||
|
||||
|
|
|
|||
|
|
@ -26,10 +26,17 @@ Description
|
|||
-----------
|
||||
//description: add a detailed description:
|
||||
The general idea is that we need meta information, and -- more precisely --
|
||||
that _we_ need to control the structure of this metadata. Because it has
|
||||
immediate consequences on the way the code can test and select the appropriate
|
||||
path to deal with some data or a given case. This brings us in a difficult
|
||||
situation:
|
||||
that _we_ need to be in control with regards to the structure of this metadata.
|
||||
Because this structure of metadata has immediate consequences with respect to the
|
||||
code's ability to test and select an appropriate path to deal with some data or
|
||||
a given clause in the high-level-Model.footnote:[To clarify the context of this
|
||||
problem: the »Builder« works like a _compiler,_ while the high-level-Model is
|
||||
similar to an attributed syntax tree. And the goal is to generate a low-level
|
||||
processing description, which implements the given structure in the Session.
|
||||
Drilling down some levels will yield a descriptor of a _medium_ (e.g. video)
|
||||
-- and so the actual task becomes to define a formalised processing scheme
|
||||
to work on something as unspecific as ``a medium''.]
|
||||
This brings us in a difficult situation:
|
||||
|
||||
* almost everything regarding media data and media handling is notoriously
|
||||
convoluted
|
||||
|
|
@ -37,13 +44,13 @@ situation:
|
|||
solution
|
||||
* we want to build on existing libraries rather then re-inventing media
|
||||
processing.
|
||||
* a library well suited for some processing task not necessarily has a type
|
||||
classification system which fits our needs.
|
||||
* a library well suited for some processing task does not necessarily have
|
||||
a type classification scheme which fits our needs.
|
||||
|
||||
The proposed solution is to create an internal Stream Type System which acts as
|
||||
a bridge to the detailed (implementation type) classification provided by the
|
||||
library(s). Moreover, the approach was chosen especially in a way as to play
|
||||
well with the rule based configuration, which is envisioned to play a central
|
||||
The proposed solution is to create an internal *Stream Type System* which acts
|
||||
as a bridge to the detailed (implementation type) classification provided by the
|
||||
library(s). Furthermore, the approach was chosen especially in a way as to mesh
|
||||
up well with the rule based configuration, which is envisioned to play a central
|
||||
role for some of the more advanced things possible within the session.
|
||||
|
||||
|
||||
|
|
@ -52,18 +59,18 @@ Terminology
|
|||
* *Media* is comprised of a set of streams or channels
|
||||
* *Stream* denotes a homogeneous flow of media data of a single kind
|
||||
* *Channel* denotes an elementary stream, which -- _in the given context_ --
|
||||
can't be decomposed any further
|
||||
can not be decomposed any further
|
||||
* all of these are delivered and processed in a smallest unit called *Frame*.
|
||||
Each frame corresponds to a time interval.
|
||||
* a *Buffer* is a data structure capable of holding one or multiple Frames of media data.
|
||||
* the *Stream Type* describes the kind of media data contained in the stream
|
||||
* the *Stream Type* describes the kind of media data contained in the stream.
|
||||
|
||||
|
||||
Concept of a Stream Type
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The Goal of our Stream Type system is to provide a framework for precisely
|
||||
describing the ``kind'' of a media stream at hand. The central idea is to
|
||||
describing the ``kind'' of a given media stream. The central idea is to
|
||||
structure the description/classification of streams into several levels.
|
||||
A complete stream type (implemented by a stream type descriptor) contains
|
||||
a tag or selection regarding each of these levels.
|
||||
|
|
@ -95,7 +102,7 @@ Working with media stream implementations
|
|||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
For dealing with media streams of various implementation type, we need
|
||||
_library_ routines, which also yield a _type classification system_ suitable
|
||||
for their intended use. Most notably, for raw sound and video data we use the
|
||||
for their intended use. Notably, for raw sound and video data we use the
|
||||
https://github.com/bplaum/gavl[GAVL] library, which defines a fairly complete
|
||||
classification system for buffers and streams. For the relevant operations in
|
||||
the Steam-Layer, we access each such library by means of a Façade; it may sound
|
||||
|
|
|
|||
|
|
@ -15,9 +15,11 @@ SystematicMetadata
|
|||
[red]#TODO# _give a short summary of this proposal_
|
||||
********************************************************************************
|
||||
|
||||
Lumiera is a metadata processing application: _Data_ is _media data_, and everything
|
||||
Lumiera is a metadata processing application: the actual _Data_ processed
|
||||
is the _media data_, used for rendering and playback, while everything
|
||||
else is _metadata_. Since our basic decision is to rely on existing libraries for
|
||||
handling data, the ``metadata part'' is what _we are building anew._
|
||||
handling the data, the ``metadata part'' is what _actually happens_ within the
|
||||
Lumiera application.
|
||||
|
||||
This RfC describes a fundamental approach towards metadata handling.
|
||||
|
||||
|
|
@ -27,7 +29,7 @@ Description
|
|||
//description: add a detailed description:
|
||||
Metadata is conceived as a huge uniform tree. This tree is conceptual -- it is
|
||||
never represented as a whole. In the implemented system, we only ever see parts
|
||||
of this virtual tree being cast into concrete data representations. These parts
|
||||
of this virtual tree as being cast into concrete data representations. These parts
|
||||
are like islands of explicitly defined and typed structure, yet they never need
|
||||
to span the whole virtual model, and thus there never needs to be an universal
|
||||
model data structure definition. Data structure becomes implementation detail.
|
||||
|
|
@ -35,11 +37,11 @@ model data structure definition. Data structure becomes implementation detail.
|
|||
Parts of the system talk to each other by _describing_ some subtree of metadata.
|
||||
This description is transferred _in the form of a tree diff:_ the receiver pulls
|
||||
a sequence of diff verbs from a diff iterator, and interpreting these verbs will
|
||||
walk him down and expand the tree in question. Sub-scopes are ``opened'' and
|
||||
populated, similar to populating a filesystem. It is up to the receiver to
|
||||
assemble these information into a suitable representation. Some receiver
|
||||
might invoke an object factory, while another serialises data into an
|
||||
external textual or binary representation.
|
||||
walk him down and expand or transform the tree in question. As part of this
|
||||
description of model changes, sub-scopes are ``opened'' and populated, similar
|
||||
to populating a filesystem. It is up to the receiver to assemble these information
|
||||
into a suitable representation. Some receiver might invoke an object factory,
|
||||
while another serialises data into an external textual or binary representation.
|
||||
|
||||
|
||||
Abstract Metadata Model
|
||||
|
|
@ -86,18 +88,22 @@ Tasks
|
|||
* scrutinise this concept to find the pitfalls [yellow-background]#WIP#
|
||||
* build a demonstration prototype, where the receiver fabricates an object [red yellow-background]#TBD#
|
||||
** the unit tests related to the _Diff System_ could be counted as such a demonstration +
|
||||
Ichthyostega:: '2029-09-13'
|
||||
Ichthyostega:: '2025-09-13'
|
||||
|
||||
Discussion
|
||||
~~~~~~~~~~
|
||||
|
||||
Pros
|
||||
^^^^
|
||||
- the basic implementation is strikingly simple, much simpler than building
|
||||
a huge data structure or any kind of serialisation/deserialisation scheme
|
||||
- parts can be combined in an open fashion, we don't need a final concept up-front
|
||||
- even complex routing and overlaying strategies become manageable, since they can be
|
||||
treated in isolation, local for a given scope and apart from the storage representation
|
||||
- the basic implementation of a meta data structure (a _property tree_) and the
|
||||
representation of a ``Diff'' is comparatively simple -- much simpler than the
|
||||
task to define and build a global data model, and get it properly connected
|
||||
to the various implementation facilities to operate on this data.
|
||||
- parts can be combined and can evolve in an open ended way, without requiring
|
||||
a finalised concept up-front,
|
||||
- even complex routing and overlaying strategies remain manageable, since routing
|
||||
and data fusion can be treated in isolation, local for a given scope and apart
|
||||
from the storage representation;
|
||||
- library implementations for textual representations can be integrated.
|
||||
|
||||
|
||||
|
|
@ -133,10 +139,12 @@ Basically common (meta) data could take on a lot of shapes between two extremes:
|
|||
- the _precise typed structure_, which also is a contract
|
||||
- the _open dynamic structure_, which leaves the contract implicit
|
||||
|
||||
The concept detailed in this RfC tries to reconcile those extremes by avoiding
|
||||
a global concrete representation; +
|
||||
this way the actual interaction -- with the necessity
|
||||
of defining a contract -- is turned into a local problem.
|
||||
The concept explained in this RfC tries to reconcile those extremes by avoiding
|
||||
a global concrete representation; instead, several interactions, each local in
|
||||
scope, can coexist on top of the abstract structure as backdrop. Each of these
|
||||
actual interactions can have its own specialised standard, which actually is
|
||||
a collaboration protocol, and is based on a common understanding of the
|
||||
_structure,_ instead of sharing actual data implementation.
|
||||
|
||||
|
||||
//Conclusion
|
||||
|
|
@ -161,15 +169,17 @@ found their way into the *Diff System*, now used as a foundation for connecting
|
|||
GUI to the Session core in Steam Layer. Especially the discussion of ``Alternatives''
|
||||
seem to indicate that an essential motivation for this RfC was to find a viable
|
||||
alternative to building the whole Application around a _central data model_ --
|
||||
which is in essence what I later transformed into a practical concept with the
|
||||
aforementioned ``Diff System''.
|
||||
which is the naive solution and tends to become a major impediment to
|
||||
hinder the further evolution within larger software projects.
|
||||
|
||||
-> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«]
|
||||
- -> see the design page regarding link:{ldoc}/design/architecture/ETD.html[»External Tree Description«]
|
||||
- -> and the corresponding technical description
|
||||
regarding the link:{ldoc}/technical/library/DiffFramework.html[Diff Framework]
|
||||
|
||||
[underline]#Bottom line#: not sure what to do with this RfC; concepts explained therein
|
||||
seem still highly relevant and central to what Lumiera is intended to become;
|
||||
but this text does not fit into the format of an RfC, nor is there a community
|
||||
of developers to discuss such a design vision appropriately.
|
||||
seem still highly relevant and central to what Lumiera is intended to become -- and they
|
||||
have already been implemented; hoever, this text does not fit into the format of an RfC,
|
||||
nor is there a community of developers to discuss such a design vision appropriately.
|
||||
|
||||
Ichthyostega:: '2025-09-13'
|
||||
|
||||
|
|
|
|||
|
|
@ -251,7 +251,7 @@ Unfortunately, nothing has happened with this RfC ever since; the reason is
|
|||
lack of developer capacity. Since this RfC is already fairly detailed, and
|
||||
no significant objections were pointed out, I am promoting this RfC to
|
||||
a __"Draft"__ now, yet leave it pending. Same as with the
|
||||
link:WebsiteNavigation.html#_comments[RfC: Website Navigation].
|
||||
link:{rfc}/WebsiteNavigation.html#_comments[RfC: Website Navigation].
|
||||
|
||||
Ichthyostega:: '2025-09-18'
|
||||
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ mutation. Some typical ``degenerated'' patterns of spelling out a diff are as fo
|
|||
|
||||
Representation of objects
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, conceived in
|
||||
While we are talking about _structured data,_ in fact the entities we are about to handle are *objects*, understood as in
|
||||
the standard flavour of object orientation, where an object is the instance of a type and offers a contract. Incidentally,
|
||||
this is not the original, ``pure'' meaning of object orientation, but the one that became prolific to bring our daily
|
||||
practice closer to the inherent structuring of modern human organisation. And in dealing with this kind of object, we
|
||||
|
|
@ -320,12 +320,16 @@ Even when this bears the danger to raise failures rather late, when it comes to
|
|||
data structure. The intention behind this whole diff approach is to transform tight coupling with strict rules
|
||||
into a loose collaboration based on a common understanding. So generally we'll assume the diff is just right,
|
||||
and if not, we'll get what we deserve.footnote:[This gives rise to a tricky discussion about loss of strictness
|
||||
and the costs incurred by that happening. We should not treat this topic in isolation; we should recall that
|
||||
loose coupling was chosen to avoid far more serious problems caused by tight coupling, and especially the
|
||||
deteriorating and poisoning effect on architecture and the further dire consequences of a global fixed common
|
||||
data model -- which prevail when used in large, not heterogenous systems.
|
||||
and the costs incurred by that choice: Assuming as starting point a fixed global data model, which is strict,
|
||||
yet we choose to open the tight connection and rather prefer a collaboration based on a ``common understanding''
|
||||
-- which seems _fuzzy_ and might be seen as an unfortunate choice. We should not treat this topic in isolation however;
|
||||
we should recall rather that loose coupling was chosen to avoid far more serious problems caused by tight coupling,
|
||||
and especially the deteriorating and poisoning effect on architecture and the further dire consequences of a global
|
||||
fixed common data model -- which prevail when used in large, and overall heterogeneous systems.
|
||||
And _when a system indeed is not homogeneous,_ we better try to make each part open-closed, open for change
|
||||
but closed against extension. This is especially true in the case of the UI.]
|
||||
but closed against extension. This is especially true in the case of the UI. And together this implies that
|
||||
we have small cohesive units of functionality; a collaboration between such units is _not_ considered
|
||||
dangerous, as long as it conforms to a well defined protocol and does not leave the local and cohesive scope.]
|
||||
|
||||
|
||||
object representation protocol
|
||||
|
|
@ -335,14 +339,27 @@ A diff is created to tell some partner about our data, and the »protocol to des
|
|||
- the ID is the object's identity and is given once, right at start, and never changed
|
||||
- we spell out any metadata first (esp. type information), followed by all attributes,
|
||||
and then followed by contents of the object's scope (children).
|
||||
- attributes are to be given such as not to counter the more stringent semantics
|
||||
of an object field or property
|
||||
- attributes must be spelled out in such a way as not to counteract the more stringent semantics
|
||||
of an object field or property. More specifically...
|
||||
|
||||
* never attempt to re-order or delete such attributes, since their presence is fixed in the class definition
|
||||
* when a field is mandatory _by its nature,_ it shall be required at construction, and the corresponding data
|
||||
is to be given with the `ins` verb causing the constructor call
|
||||
needs to be given immediately with the `ins` verb causing the constructor call
|
||||
* on the other hand, the data for an optional field, when present, shall be spelled out by `ins` verb
|
||||
after construction, with the first _population diff._
|
||||
* we do not support attribute map semantics (or extended ``object properties'' of any kind). +
|
||||
If necessary, treat them as nested entity with map semantics
|
||||
* the diff can address an attribute by its key; in the concrete binding to an object this will
|
||||
cause a linear search through all attribute handlers to find the proper one, responsible for the
|
||||
specific attribute given
|
||||
* we do not support attribute map semantics (or extended ``object properties'' of any kind, as many
|
||||
script languages do). If it is deemed necessary, in special cases, to have a _map_ of `(key ⟼ value)`
|
||||
bindings, then do not represent them as object attributes, rather treat them as nested entity with map
|
||||
semantics.footnote:[The `TreeMutator` provides a ready-made binding to STL containers, with a special
|
||||
case to address a map. But this remains a borderline case and this usage to apply a diff to a map
|
||||
can be tricky (due to the ordering constraints of a map).]
|
||||
|
||||
TIP: nothing has been said about _detecting_ differences in object or property trees;
|
||||
it is assumed that solving this especially nasty problem can be avoided, since
|
||||
the _emanation_ of a diff in Lumiera can always be assumed to have additional
|
||||
knowledge regarding the location of the change, and thus does not need to
|
||||
``find'' the changed data. The reasoning behind this assumption is that
|
||||
the diff messages are generated in response to an _Event._
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
** - at the bottom we use an adaptation layer in the form of a traits template,
|
||||
** with two concrete specialisations of the ContainerTraits for vector-like
|
||||
** and map-like collections
|
||||
** - on top of this the CollectionBinding is established to establish a kind of
|
||||
** - on top of this the CollectionBinding is established to provide a kind of
|
||||
** generic access protocol for consuming a collection guided by diff instructions
|
||||
** - the third level then holds the actual TreeMutator implementation, embodied into
|
||||
** the ChildCollectionMutator template, which in fact translates and delegates
|
||||
|
|
@ -48,7 +48,7 @@
|
|||
** provided by the client of this collection binding. The entrance point to this
|
||||
** DSL layer is the _DefaultBinding, which is established by wrapping the actual
|
||||
** collection into the concrete CollectionBinding at the point where the builder
|
||||
** is created. The further DSL verbs on the CollectionBindingBuilder just server
|
||||
** is created. The further DSL verbs on the CollectionBindingBuilder just serve
|
||||
** to provide or overlay some lambdas to fill in the flexible parts of the binding.
|
||||
**
|
||||
** And these flexible parts are mostly concerned with the _actual contents_ of the
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load diff
Loading…
Reference in a new issue