From 051cb31e283fa92c22c5e839e58839097727e740 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sun, 5 Oct 2025 02:02:22 +0200 Subject: [PATCH] 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. --- doc/design/architecture/ETD.txt | 12 +- doc/devel/meeting_summary/2008-02-01.txt | 2 +- doc/devel/meeting_summary/2008-04-03.txt | 3 +- doc/devel/meeting_summary/2008-06-06.txt | 2 +- doc/devel/rfc/AllPluginInterfacesAreC.txt | 2 +- doc/devel/rfc/ApplicationStructure.txt | 29 +- doc/devel/rfc/ConfigLoader.txt | 36 +- doc/devel/rfc/DataBackend.txt | 51 +- .../rfc/DeveloperDocumentationStructure.txt | 24 +- doc/devel/rfc/DevelopmentFramework.txt | 57 +- .../rfc/DistributedDevelopmentFramework.txt | 51 +- doc/devel/rfc/GitCommitMessageFormat.txt | 2 +- doc/devel/rfc/GitSubmoduleTransistion.txt | 32 +- doc/devel/rfc/GlobalInitialization.txt | 18 +- doc/devel/rfc/InterfaceNamespaces.txt | 15 + doc/devel/rfc/Manifest.txt | 4 +- doc/devel/rfc/MasterRepositorySetup.txt | 1 + doc/devel/rfc/RenderOptimizer.txt | 31 +- doc/devel/rfc/ScriptingLanguage.txt | 9 +- doc/devel/rfc/SkillsCollection.txt | 4 +- doc/devel/rfc/StreamTypeSystem.txt | 35 +- doc/devel/rfc/SystematicMetadata.txt | 58 +- doc/devel/rfc/WebsiteSupportMarkup.txt | 2 +- .../ConfigLoader.txt | 0 .../DataBackend.txt | 0 .../DistributedDevelopmentFramework.txt | 0 .../GitSubmoduleTransistion.txt | 0 .../ScriptingLanguage.txt | 0 .../SkillsCollection.txt | 0 doc/technical/library/DiffFramework.txt | 39 +- .../diff/tree-mutator-collection-binding.hpp | 4 +- wiki/thinkPad.ichthyo.mm | 874 +++++++++++++++++- 32 files changed, 1266 insertions(+), 131 deletions(-) rename doc/devel/{rfc_parked => rfc_dropped}/ConfigLoader.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/DataBackend.txt (100%) rename doc/devel/{rfc_final => rfc_dropped}/DistributedDevelopmentFramework.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/GitSubmoduleTransistion.txt (100%) rename doc/devel/{rfc_pending => rfc_dropped}/ScriptingLanguage.txt (100%) rename doc/devel/{rfc_parked => rfc_dropped}/SkillsCollection.txt (100%) diff --git a/doc/design/architecture/ETD.txt b/doc/design/architecture/ETD.txt index b2a828f94..0adac6747 100644 --- a/doc/design/architecture/ETD.txt +++ b/doc/design/architecture/ETD.txt @@ -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*. diff --git a/doc/devel/meeting_summary/2008-02-01.txt b/doc/devel/meeting_summary/2008-02-01.txt index 1f4767144..919f48c44 100644 --- a/doc/devel/meeting_summary/2008-02-01.txt +++ b/doc/devel/meeting_summary/2008-02-01.txt @@ -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. diff --git a/doc/devel/meeting_summary/2008-04-03.txt b/doc/devel/meeting_summary/2008-04-03.txt index 0cbeffcc6..05248b154 100644 --- a/doc/devel/meeting_summary/2008-04-03.txt +++ b/doc/devel/meeting_summary/2008-04-03.txt @@ -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]## 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) diff --git a/doc/devel/meeting_summary/2008-06-06.txt b/doc/devel/meeting_summary/2008-06-06.txt index d6dda871a..9a9bdb468 100644 --- a/doc/devel/meeting_summary/2008-06-06.txt +++ b/doc/devel/meeting_summary/2008-06-06.txt @@ -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, diff --git a/doc/devel/rfc/AllPluginInterfacesAreC.txt b/doc/devel/rfc/AllPluginInterfacesAreC.txt index 74c155b1c..f79f4d1b5 100644 --- a/doc/devel/rfc/AllPluginInterfacesAreC.txt +++ b/doc/devel/rfc/AllPluginInterfacesAreC.txt @@ -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' diff --git a/doc/devel/rfc/ApplicationStructure.txt b/doc/devel/rfc/ApplicationStructure.txt index 71f4a6d34..f08c94c3e 100644 --- a/doc/devel/rfc/ApplicationStructure.txt +++ b/doc/devel/rfc/ApplicationStructure.txt @@ -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] diff --git a/doc/devel/rfc/ConfigLoader.txt b/doc/devel/rfc/ConfigLoader.txt index 7e19d21ef..ca14143a8 100644 --- a/doc/devel/rfc/ConfigLoader.txt +++ b/doc/devel/rfc/ConfigLoader.txt @@ -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' ~~ +.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...~ '''''''''''''''' diff --git a/doc/devel/rfc/DataBackend.txt b/doc/devel/rfc/DataBackend.txt index 380d37243..5210a2427 100644 --- a/doc/devel/rfc/DataBackend.txt +++ b/doc/devel/rfc/DataBackend.txt @@ -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] diff --git a/doc/devel/rfc/DeveloperDocumentationStructure.txt b/doc/devel/rfc/DeveloperDocumentationStructure.txt index 041873654..08270ad25 100644 --- a/doc/devel/rfc/DeveloperDocumentationStructure.txt +++ b/doc/devel/rfc/DeveloperDocumentationStructure.txt @@ -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' ~~ @@ -190,7 +190,7 @@ Ichthyostega:: 'Mo 09 Sep 2013 01:01:25 CEST' ~~ .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: diff --git a/doc/devel/rfc/DevelopmentFramework.txt b/doc/devel/rfc/DevelopmentFramework.txt index 34c53cf8f..0a430d65e 100644 --- a/doc/devel/rfc/DevelopmentFramework.txt +++ b/doc/devel/rfc/DevelopmentFramework.txt @@ -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] diff --git a/doc/devel/rfc/DistributedDevelopmentFramework.txt b/doc/devel/rfc/DistributedDevelopmentFramework.txt index eabc5dee9..9f8e50592 100644 --- a/doc/devel/rfc/DistributedDevelopmentFramework.txt +++ b/doc/devel/rfc/DistributedDevelopmentFramework.txt @@ -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] diff --git a/doc/devel/rfc/GitCommitMessageFormat.txt b/doc/devel/rfc/GitCommitMessageFormat.txt index ce27b6692..0c65edcc1 100644 --- a/doc/devel/rfc/GitCommitMessageFormat.txt +++ b/doc/devel/rfc/GitCommitMessageFormat.txt @@ -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. diff --git a/doc/devel/rfc/GitSubmoduleTransistion.txt b/doc/devel/rfc/GitSubmoduleTransistion.txt index a2645b13c..1597105ed 100644 --- a/doc/devel/rfc/GitSubmoduleTransistion.txt +++ b/doc/devel/rfc/GitSubmoduleTransistion.txt @@ -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] diff --git a/doc/devel/rfc/GlobalInitialization.txt b/doc/devel/rfc/GlobalInitialization.txt index 24359c7c8..43a73c72b 100644 --- a/doc/devel/rfc/GlobalInitialization.txt +++ b/doc/devel/rfc/GlobalInitialization.txt @@ -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' ~~ +💡 + +[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: '''' diff --git a/doc/devel/rfc/InterfaceNamespaces.txt b/doc/devel/rfc/InterfaceNamespaces.txt index 357bb75b7..6c0f192a4 100644 --- a/doc/devel/rfc/InterfaceNamespaces.txt +++ b/doc/devel/rfc/InterfaceNamespaces.txt @@ -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] diff --git a/doc/devel/rfc/Manifest.txt b/doc/devel/rfc/Manifest.txt index 0c2d5db73..c317694c6 100644 --- a/doc/devel/rfc/Manifest.txt +++ b/doc/devel/rfc/Manifest.txt @@ -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 diff --git a/doc/devel/rfc/MasterRepositorySetup.txt b/doc/devel/rfc/MasterRepositorySetup.txt index f0845a112..81d092acc 100644 --- a/doc/devel/rfc/MasterRepositorySetup.txt +++ b/doc/devel/rfc/MasterRepositorySetup.txt @@ -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 diff --git a/doc/devel/rfc/RenderOptimizer.txt b/doc/devel/rfc/RenderOptimizer.txt index b2312b73e..11919b011 100644 --- a/doc/devel/rfc/RenderOptimizer.txt +++ b/doc/devel/rfc/RenderOptimizer.txt @@ -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' '''' diff --git a/doc/devel/rfc/ScriptingLanguage.txt b/doc/devel/rfc/ScriptingLanguage.txt index d7e09e178..a33387892 100644 --- a/doc/devel/rfc/ScriptingLanguage.txt +++ b/doc/devel/rfc/ScriptingLanguage.txt @@ -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' ~~ 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] diff --git a/doc/devel/rfc/SkillsCollection.txt b/doc/devel/rfc/SkillsCollection.txt index 978075c6a..8a78788f5 100644 --- a/doc/devel/rfc/SkillsCollection.txt +++ b/doc/devel/rfc/SkillsCollection.txt @@ -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' diff --git a/doc/devel/rfc/StreamTypeSystem.txt b/doc/devel/rfc/StreamTypeSystem.txt index 7a2530244..4c4baa8b5 100644 --- a/doc/devel/rfc/StreamTypeSystem.txt +++ b/doc/devel/rfc/StreamTypeSystem.txt @@ -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 diff --git a/doc/devel/rfc/SystematicMetadata.txt b/doc/devel/rfc/SystematicMetadata.txt index c0ca62548..8e6a5b97a 100644 --- a/doc/devel/rfc/SystematicMetadata.txt +++ b/doc/devel/rfc/SystematicMetadata.txt @@ -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' diff --git a/doc/devel/rfc/WebsiteSupportMarkup.txt b/doc/devel/rfc/WebsiteSupportMarkup.txt index 3ac9fbafd..6bff1347b 100644 --- a/doc/devel/rfc/WebsiteSupportMarkup.txt +++ b/doc/devel/rfc/WebsiteSupportMarkup.txt @@ -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' diff --git a/doc/devel/rfc_parked/ConfigLoader.txt b/doc/devel/rfc_dropped/ConfigLoader.txt similarity index 100% rename from doc/devel/rfc_parked/ConfigLoader.txt rename to doc/devel/rfc_dropped/ConfigLoader.txt diff --git a/doc/devel/rfc_parked/DataBackend.txt b/doc/devel/rfc_dropped/DataBackend.txt similarity index 100% rename from doc/devel/rfc_parked/DataBackend.txt rename to doc/devel/rfc_dropped/DataBackend.txt diff --git a/doc/devel/rfc_final/DistributedDevelopmentFramework.txt b/doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt similarity index 100% rename from doc/devel/rfc_final/DistributedDevelopmentFramework.txt rename to doc/devel/rfc_dropped/DistributedDevelopmentFramework.txt diff --git a/doc/devel/rfc_parked/GitSubmoduleTransistion.txt b/doc/devel/rfc_dropped/GitSubmoduleTransistion.txt similarity index 100% rename from doc/devel/rfc_parked/GitSubmoduleTransistion.txt rename to doc/devel/rfc_dropped/GitSubmoduleTransistion.txt diff --git a/doc/devel/rfc_pending/ScriptingLanguage.txt b/doc/devel/rfc_dropped/ScriptingLanguage.txt similarity index 100% rename from doc/devel/rfc_pending/ScriptingLanguage.txt rename to doc/devel/rfc_dropped/ScriptingLanguage.txt diff --git a/doc/devel/rfc_parked/SkillsCollection.txt b/doc/devel/rfc_dropped/SkillsCollection.txt similarity index 100% rename from doc/devel/rfc_parked/SkillsCollection.txt rename to doc/devel/rfc_dropped/SkillsCollection.txt diff --git a/doc/technical/library/DiffFramework.txt b/doc/technical/library/DiffFramework.txt index c8048f45d..6fca425a1 100644 --- a/doc/technical/library/DiffFramework.txt +++ b/doc/technical/library/DiffFramework.txt @@ -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._ diff --git a/src/lib/diff/tree-mutator-collection-binding.hpp b/src/lib/diff/tree-mutator-collection-binding.hpp index bdb24b15a..ef237a583 100644 --- a/src/lib/diff/tree-mutator-collection-binding.hpp +++ b/src/lib/diff/tree-mutator-collection-binding.hpp @@ -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 diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index cc53d4d45..08699e5bf 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -161051,10 +161051,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + - + @@ -161164,8 +161165,12 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161212,7 +161217,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161232,7 +161237,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161344,11 +161349,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - - + + - + @@ -161368,6 +161373,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161379,6 +161385,25 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + + +

+ Das erachte ich als dringend, denn wer schreibt, der bleibt:  der typische, durchschnittliche »Techie« hat keine Ahnung vom Arbeiten mit Medien und auch keine Ahnung von Interaction-Design; die typsichen Feature-Requests, mit denen wir geflutet werden, kann man weitgehend ignorieren, es wäre schädlich für die Applikation, sie umzusetzen, bevor ein vollständiges GUI/Workflow-Konzept mit strikten Richtlinien da ist. Und ein solches Konzept auszuarbeiten, kostet Zeit und Kraft. Es ist strategisch sinnvoll, diesen Aufwand von der laufenden Entwicklungstätigkeit abzuzweigen, hoffentlich bevor das Thema allgemein bemerkt wird.  Wenn man »die Leute« machen läßt, dann wird Lumiera die ursprüngliche Vision verfehlen. Denn man kennt heut nur, worauf einen der industrielle Prozeß konditioniert, und man will dann bloß das Gleiche, aber umsonst. +

+ + + + + @@ -161487,14 +161512,29 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + - + + + + + + + + + - + + + @@ -161510,9 +161550,13 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + + + + @@ -161539,6 +161583,28 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + + +

+ Das ist entstanden, weil Benny zunächst allgemein helfen/beitragen wollte; ich habe vorgeschlagen, er solle sich mit dem Thema Video-Output beschäftigen, unter der Maßgabe, ob es da bereits fertige und einfach nutzbare Frameworks gibt. Er hat dann relativ bald sich auf GStreamer konzentrierte, sehr schnell ein Tutorial-Beispiel gehabt für einen Video-Player, ist an der Stelle aber stecken geblieben. Im Rückblick muß ich sagen, daß GStreamer für unser Thema vermutlich keine gute Quelle ist — man bekommt nur ein massives Framework zu fassen — allerdings hat sich Benny auch nicht selbständig lateral bewegt. Im Frühjahr 2025 haben wir überlegt, was wir zur FrOSCon machen könnten; es war bereits beschlossen, daß wir nun jedes Jahr mit mindestens einem Vortrag präsent sein wollen. Ich hatte dann die Idee, diese Recherche gemeinsam weiterzuführen, da ich die Ergebnisse nun absehbar demnächst brauche, um die Engine zu testen. +

+ + + + + + + + + @@ -161707,7 +161773,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -161728,6 +161794,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + @@ -161861,8 +161928,9 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + + @@ -162655,7 +162723,7 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo - + @@ -162664,7 +162732,18 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo

+ + + + + +

+ Das ist ein Geschehen, das nicht „absichtlich betrieben“ wird, sondern sich den Menschen aufdrängt, in der Form eines Anspruches: Sachverhalte und Umstände erscheinen plötzlich in einem anderen Licht, in einem Zusammenhang, und diejenigen, die das nicht sehen, nimmt man plötzlich als unmoralisch wahr. +

+ + + @@ -163269,6 +163348,260 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + + +

+ ...so meine Schlußfolgerung; denn es fällt auf, daß ich keinen  der noch bestehenden Links in der Wayback-Maschine finde... +

+ + + + + + + + +

+ einige meiner Texte habe ich als HTML gespeichert +

+ + + + + + + + + + + + +

+ andererseits: alle wichtigen Ideen für Lumiera waren von Anfang an da +

+ + + + + + + + + + + + + + + + + + +

+ ...denn das ist das ist dann irgend ein Text, der 15 Jahre später in Git auftaucht; für den »Cinelerra_woes«-Text habe ich das wenigstens zeitnah gemacht +

+ + + + + + + +

+ einigermaßen beweiskräftig ist Publikation, welche +

+
    +
  • + entweder auf Archive.org aufgezeichnet wurde +
    • +
  • + oder zeitnah in einem public-Git-Repo lag +
    • +
  • + oder in einem »geschlossenen Format« (wie PDF) vorliegt +
    • +
+

+ ...denn in diesen Fällen kann man zumindest schon durch den Kontext eine gewisse Beweiskraft ableiten. Für alle anderen Formate gilt sets, daß man sie im Grunde jederzeit erstellen könnte, im Besonderen wenn die eigentliche Formatierung viel später oder in einem neuen Format stattfindet. Solche Dokumente haben dann nur einen Wert wie eine Zeugenaussage +

+ + + + + + + + + + +

+ ...außer »Cinelerra woes« ... +

+

+ ich bin halt ein unverbesserlicher Sammler, und nachdem ich wußte, wonach ich suchen muß, hab ich sie auch ganz schnell gefunden +

+ + + + + + + +

+ ...ich frage mich nämlich inzwischen oft, wann ich mir diese Ideen zugezogen habe; diese Seiten belegen für mich, daß es ich bei Lumiera im Kern um eine »Vision« handelt, die ich 2007 hatte. Und nicht um ein Konzept, welches ich mir durch endloses Nachdenken über viele Jahre ohne Realitätskontakt »zusammengesponnen« hätte.
Also im Grunde sehr ähnlich, wie bei Christian, der ja wohl auch damals bereits die komplette Plugin-Applikation vor seinem geistigen Auge gesehen hat +

+ + + + + + + +

+ Sofern Lumiera scheitert, oder zu etwas ganz anderem wird, oder überhaupt jemand sich die Mühe macht, die Historie auszuleuchten — dann könnten solche Seiten auch erheblich negativ ausgedeutet werden: so eine absurde Idee, und sowas von weltfern... und dann hält man daran auch noch jahrelang fest, anstatt sich »vernünftiger Methoden« zu bedienen oder sich »wertvolle Ziele« zu setzen. +

+ + + + + + + + + + + + + + + + + + +

+ dann sind es nämlich wohl nur drei Seiten; alle anderen Seiten finden sich nahezu vollständig als erste Versionen späterer RfCs +

+ + + + + + + + + + +

+ 2008-03-06T06:22:27+01:00 : ProcPlacementMetaphor.html +

+

+ 2008-03-06T06:22:56+01:00 : ProcBuilder.html +

+

+ 2008-03-06T06:23:09+01:00 : ArchitectureOverview.html +

+

+ 2008-03-06T06:23:38+01:00 : Cinelerra_woes.html +

+

+ 2008-03-06T06:23:48+01:00 : best_practices.html +

+

+ 2008-03-06T06:24:05+01:00 : Cin3_Project_Proposal.html +

+

+ 2008-03-06T06:24:22+01:00 : Possibilities_at_hand.html +

+ + + + + + + + + + + + +

+ ...im zweiten Teil hat dieser Capture vom 2008 deutlich überarbeitete Inhalte, im Vergleich zu der Version, die ich 2011 für die Historien-Seite publiziert habe. Überdies bin ich (lt. Git) damals 2011 von Moin-Moin-Markup ausgegangen. Also  mußte ich irgendwo eine noch ältere Version gespeichert haben, als dieser capture hier von 2008. +

+

+ Beschluß: für die Historien-Seite bleibe ich bei der älteren (roheren) Fassung, aber ich dokumentiere diese Fassung trotzdem hier in der Git-Historie von dem Seitenbranch, den ich im Moment aufbaue +

+ + + + + + + + + + + + +

+ Taucht erstmals in einem Merge-Commit im Mai 2008 auf (da habe ich das SVG wohl noch mit reingestopft) +

+

+ +

+

+ commit c0d7ae1aa2073e4e5b29f864d32a639c2864e9a1 +

+

+ Merge: b5d2e9486 2e58b02b8 +

+

+ Author: Ichthyostega <prg@ichthyostega.de> +

+

+ Date:   Tue May 27 02:11:35 2008 +0200 +

+

+ +

+

+     Merge added builder documentation +

+ + + + + + + + + + + + + + + + +

+ ...sie stammen alle (mit Ausnahme von »Cinelerra woes«, von dem ich noch original-MoinMoin-Markup hatte) aus einem HTML-Snapshot im März 2008. Tatsächlich habe an ganz wenigen Stellen nun doch die Grammatik repariert, denn manche Sätze waren nahezu unverständlich in der Originalform. Außerdem habe ich manuell auf Asciidoc umgeschrieben, und dabei auch bisweilen die Formatierung minimal angepaßt (Umbrüche, Titel-Level vereinheitlicht, an einer Stelle eine Bullet-List aus einer Aufzählung gemacht) +

+ + + + + + + + + + @@ -163311,10 +163644,421 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + + + + + +

+ Da die RfCs immer noch als eine wichtige Ebene in unserer Dokumentation gelten, sollte ihr Inhalt nicht gleichgültig sein, sondern auf Relevanz geprüft werden. +

+ + + + + + +

+ bisweilen ist die Formulierung so unbeholfen, daß das Gemeinte kaum verständlich ist; manchmal fehlt etwas Kontext und ein paar Hinweise wären sinnvoll +

+ + + + + + + +

+ Es gibt einige RfCs aus der allerersten Zeit, die im Rückblick gradezu visionär wirken — oft aber ist bei diesen Entwürfen die Tragweite nicht klar. Daher sollten solche RfCs behutsam durch Kommentare und Textredaktion nachgeschärft und eingeordnet werden. Nicht zuletzt auch deshalb, weil man weiterhin auf diese Einträge wird verlinken müssen. +

+ + + + + + + +

+ eine Menge RfCs waren politisch aufgeladen +

+ + + + + +

+ Es gab eine Zeit erheblicher Spannungen zwischen mir und Christian, die gekennzeichnet war von einem Ringen um den Stli des Projekts. Stil hier im weiten Sinn. Dem entsprechend finden sich viele doppelbödige Formulierungen, oder Vorschläge, die — nüchtern betrachtet — nachgerade durchgeknallt wirken. Auch für diese RfCs halte ich eine gewisse Einordnung für angezeigt Das kann durch einen historischen Zusatz erfolgen, oder dadruch, daß ich sie in aller Form verwerfe und mir dadurch das die Deutungshoheit in der Sache aneigne. Das kann bisweilen eine Gratwanderung sein — denn es geht mir nicht darum, zu siegen oder Recht zu haben, sondern es geht mir darum, das Projekt der Sache angemessen zu navigieren. Allerdings ist das, „was Sache ist“, ein Urteil, das ich fälle, nachdem ich duch die Sachverhalte durchgegangen bin, und zwar, sein vielen Jahren, allein. +

+ + + + + + + +

+ Eine ganze Reihe der RfCs aus der allerersten Zeit gehören in diese Kategorie: sie entwerfen einen Arbeitsstil im Projekt, oft auch mit einer bestimmten Erwarung und Vorstellung bezüglich Formalismen und Automatisierung. Bezeichnenderweise stammen alle diese RfC von Christian. Einige wenige beschreiben Projekt-Konventionen, die sich tatsächlich auch so gehalten haben (z.B. die Anordnung der Repositories). Einge ganze Reihe weiterer Vorschläge erscheint mir komplett weltfremd (wie z.B. daß ein größeres Projekt funktionieren könnte, indem einfach jeder in Git eincheckt und nach belieben merged was gefällt, oder daß man jedwede Projektorganisation auf Git-commits zurückführen kann). Dem entsprechend hat auch nie jemand ernsthaft versucht, im Projekt so zu arbeiten. Das sollte dann auch im jeweiligen RfC vermerkt sein. Und schließlich gibt es einige wenige RfC, die die Organisation aus der Anfangszeit beschreiben; diese sind dadruch obsolet geworden, daß ich nun schon so ewig lange allein bin, und dem entsprechend anders vorgehen kann und muß. +

+ + + + + + + + + + +

+ explizit wieder in die Design-Phase zurück +

+ + + + + + + +

+ habe ich schon vor einigen Jahren explizit verworfen +

+ + + + + + + + + + + + + + + + +

+ Dieser RfC ist wieder so typisch Christian: er besteht aus einem sehr naheliegenden und sinnigen Vorschlag (Tags verwenden, Tags automatisch generieren, Tag-Verzeichnis generieren). Aber dann besteht er größtenteils aus einer teils genialen, teils unausgegorenen Idee, die sofort absolut gesetzt wird: eine Ontology über Tags definieren, mit logischen Operationen darauf. +

+

+ +

+

+ Diese Art Vorschläge bringen mich immer wieder in das gleiche Dilemma +

+
    +
  • + dem einfachen Teil würde ich gerne zustimmen, er müßte aber konkret ausgearbeitet werden +
    • +
  • + zu dem weitgreifenden Vorschschlag wäre wohl erst mal ein Prototyp notwendig, aber in eienr Art, die nicht gleich endgülitig Fakten schafft und andere Möglichkeiten verbaut. +
    • +
+

+ Und mit beiden Problemen läßt einen Christian dann allein; er hätte nur noch Interesse daran, einen extrem pfiffigen Prototypen für den weitreichenden Vorschlag ganz minimalistisch zu implementieren und dann das Thema abzuhaken. Ich finde mich dann immer wieder in dem ärgerlichen Dilemma: entweder ich lasse alle möglichen Vorschläge offen hängen, und dann laufe ich Gefahr, daß Christian irgendwann einfordert, das nun einfach mal zu akzeptieren (ohne weiter was für zu tun). Oder ich bin derjenige, der seine Vorschläge komplett verwirft, oder ich bin derjenige, der seine Vorschläge dann runter-strippt und implementiert, und mit den sich dann zeigenden konzeptionellen Problemen allein gelassen wird (so geschehen beim Lock-Cycle-detector, bei den Thread-Wrappern, seinem Interface/Plugin-System oder der Configuration). +

+

+ +

+

+ Hier entscheide ich mich dafür, den Vorschlag komplett zu verwerfen, mit den Argumenten, die ich damals schon als Diskussionsbeitrag geschrieben habe. Und zwar mache ich das aus Sorge, daß später irgend jemand auf die Idee kommt, den Vorschlag mal zu implementieren — was bestenfalls nutzlos wäre, schlimmstenfalls aber andere, wichtige Einrichtungen behindert oder verdirbt (man denke nur mal daran, wenn ein Website-Cross-Link-Generator implementiert wird, aber nur limitiert auf die hier vorgeschlagene Semantik) +

+ + + + + + + + +

+ Dieser RfC ist ein Kuriosum — eine »Duftmarke« aus der ersten Zeit. +

+

+ Christian hat das vorgeschlagen im März 2008; damals waren wir schon in einer festen Projekt-Organisation als »Lumiera« unterwegs. Ich kann mich definitiv nicht mehr erinnern, was ich damals von dem Vorschlag gehalten habe. Ich weiß noch, das Christian eine heftige Aversion gegen Bugzilla hatte (und wohl auch gegen jede Art von Ticket-Management). +

+

+ +

+

+ Diese Erinnerung schreibe ich jetzt auch in das Ticket rein, denn was soll man sonst damit machen? So für sich betrachtet (aus gegenwärtigem Kontext) erscheint es nur absurd, einen solchen RfC überhaupt zu formulieren, aber ich sollte Christian den Kredit geben, daß er ein Problem gesehen hat.
+

+

+ +

+

+ Jedenfalls klar ist, wenig später hatten wir ein Trac, dafür habe ich gesorgt, und Christian hat es zwar anfangs auch genutzt, aber letztlich immer für "Ichthyos Ding" gehalten. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ daher müssen die meisten RfCs aus heutiger Sicht neu beurteilt  werden +

+ + + + + + + + + + + + + + + + + +

+ Diese dokumentieren den Stil und das »Mindset« aus der Zeit der entstehenden Bewegung, aus der später das Lumiera-Projekt wurde. Typisch für diese RfCs ist, daß sie ein wesentliches Element des Stils im Projekt bereits vorgreifend darstellen, aber typischwerise auch total „über das Ziel“ hinausschießen, indem Methoden und Verfahren vorgeschlagen werden, oder gar schon als gelebte Praxis deklariert werden, welche — nüchtern betrachtet — in unserer gegenwärtigen Zeit nicht funktionieren und ihren Zweck niemals erfüllen können. Solche RfC müssen explizit eingeordnet werden +

+ + + + + + + + + + + + + + + + + + + +

+ ⟹ heißt: hier hat er eine Vision, die ihm wichtiger als alles andere ist +

+ + + + + + + +

+ ...ich fand Christian's Vorschläge in diese Richtung immer nur etwas „sonderbar“ und realtitätsfern, meist so völlig überzogen, daß ich nur „ja ja“ gesagt habe (wohl wissend, daß nichts konkretes folgend wird). Dumm gelaufen. Jetzt haben wir ein ganzes Bündel von solchen RfCs, und alle wurden entweder durchgepresst, oder durchgewunken, ohne weitere Diskussion. Ausnahme: die »Semantic Tags« von 2012. Da habe ich im Dev-Meeting kontra gegeben, und es kam bereits zueiner überraschend hitzigen Diskussion. +

+ + + + + + + + +

+ "points define a periphery" ...  möglicherweise hilft es, nicht an den jeweiligen Vorschlägen hängen zu bleiben, sondern mich zu fragen: worauf will Christian hinaus? +

+

+ +

+
    +
  • + sein allererster RfC war also, daß wir alle Bugtracker, und sonstigen Orga-Tools durch Git + Automatisierung ersetzen +
    • +
  • + das nächste war das Manifest. Darin ging es inhaltlich nicht um Cinelerra, sondern darum, ein Projekt "möglichst einfach und zugänglich" zu machen. Jeder soll tun was er für richtig hält, und dadurch lösen sich alle Probleme von selber (wenn man die Leute nur durch clevere Automatisierung und Git zusammenschaltet ⟹ das ist die Idee der »Unsichtbaren Hand« aus dem Liberalismus) +
    • +
  • + dann hat er x weitere Aktionen und RfCs gestartet, die alle darauf hinauslaufen, eine Infrastruktur zu schaffen (dem Projekt hat das enorm geholfen) +
    • +
  • + und dann hat er monatelang überhaupt nichts beigetragen, sondern hat sich mit vollem Eifer in das uWiki-Projekt geworfen, aber es exakt in dem Moment aufgegeben, als klar war, daß es nicht genügt, alles über einen eleganten Bootstrap zu verschalten, sondern daß tatsächliche Knochenarbeit (Webentwicklung) notwendig wäre. Nicht daß Christian nicht hart arbeiten kann, aber wenn man sich durch dicke Bretter bohren muß und Mengen von Details ordnen, dann ist das nicht seine Vision, sondern wohl ehr eine Bankrotterkärung. +
    • +
  • + danach hat er eine Menge Infrastruktur im Backend hochgezogen, die nur darauf zielt, die Arbeit für den Entwickler möglichst einfach zu machen, und dafür bestimmte Schemata global enforced. Er hat dann immer eingefordert, daß sich alle von jetzt an daran halten müssen, denn sonst wirkt das ja nicht +
    • +
  • + als nächstes kam das Thema "Plug-ins" + Lua. Auch das zielt darauf, alles möglichst modular, flach und einfach zugänglich zu machen, um aufgrund jeder neu auftauchenden Idee alles mit allem neu verschalten zu können +
    • +
  • + kurz darauf hat Christian mehrere Initiativen gestartet, den globalen Applikations-Rahmen "in den Griff" zu bekommen. Mich hat das sehr empört (und ich hab entsprechend giftig reagier), denn er hat meine bereits geleistete Arbeit komplett ignoriert und dann nach meinem Hinweis als "Overengineering" beiseite geschoben. Ich hab das nicht einordnen können, denn es war offensichtlich nicht persönlich gemeint. Sondern er wollte Dinge beiseite schieben, die seine Vision stören +
    • +
  • + sehr ähnlich lief's dann beim Config-System, wie ich jetzt aus den Meeting-Summaries rekonstruieren konnte. Alle anderen Devs haben hin darauf hingewiesen, daß es zu dem Thema zig ausgereifte Lösungen gibt. Darauf ist er nicht einmal eingegangen (und hat sich auch nicht erkenntlich mit diesen Lösungen auseinandergesetzt). Was ich so deute, daß er an das Thema grundsätzlich ganz anders rangehen wollte. Christian zeigte auch keinerlei Interesse an einer Requirement-Analyse, was ich so deute, daß er das Thema als Vehikel gesehen hat, um seine Vision voranzubringen. Auch der bestehende Implementation-Draft bestätigt diese Lesart: er ist bezüglich der Nutzbarkeit derart rudimentär, daß man ihn grade eben mit Tricks durch einen Unit-Test prügeln kann. Aber ein elaboriertes System von Matching- und Ersetzungregeln direkt in der Stringverarbeitung ist sehr detailliert durchdacht und angelegt worden. +
    • +
  • + Auch später noch, nachdem Christian schon nicht mehr aktiv beigetragen hat, kamen als Vorschläge zu aktuellen Problemen manchmal unglaublich elegante Abkürzungs-Lösungen (wie die Linkfarm), deren Stärke darin besteht, das eigentliche Problem aus den Angeln heben. Meist aber kamen irgendwelche Vorschläge für Automatisierung und clevere Textersetzungs-Regeln (Semantic Tags, Git commit message format, Vorschläge, Metadata-Hooks als Overlay direkt in die Datenstrukturen im Backend einzubauen, Vorschläge für Caching an allen möglichen Stellen, oder die Idee, Tests elaboriert automatisch zu generieren) +
    • +
+ + + + + + + +

+ Ich war jetzt lange Zeit allein, und insofern waren die RfC egal, denn ich weiß ja, was geschehen ist. Da ich aber nun das Ziel ins Auge fasse, ein Team aufzubauen, ändert sich die Situation. Ich muß nun dafür sorgen, meine Deutungshoheit zu ratifizieren. Ich habe diese Deutungshoheit durch harte Arbeit erlangt, nicht durch Magie. Alle entscheidenden Durchbrüche in den letzten Jahren beruhen vor allem auf Denkarbeit, also viele Stunden Reflexion, die auch aufgeschrieben und wieder gelesen wird. +

+

+ +

+

+ Meine Haltung zu dem, was Christian's Vision sein könnte (letztlich meine Auslegung!), hat sich in den letzten Jahren geändert. Und zwar von „schaug' mer mal was es in Beweung setzt“ auf „ich sehe jetzt wohin das führt und ich will nicht in dieser Zukunft leben, sondern in einer anderen“. +

+

+ Konsequenzen +

+
    +
  • + Ich *DEUTE* Christians Vision als Teil eines Trends zur Industrialisierung. Das ist etwas, was mit den Menschen geschieht, ohne daß es absichtsvoll geplant wird. +
    • +
  • + Ich *NAVIGIERE* das Projekt in Richtung einer möglichen Dialektik dazu (⚠ Achtung: nicht in Richtung von Tradition und Konservativismus; ich gebrauche den Begriff »Handwerk« als Vehikel). +
    • +
+ + + + + + + + + + + + + + + +

+ Diese forumulieren wesentliche Elemente der Vision aus, unter der das Projekt begonnen wurde. Einige dieser RfC wurden sofort beschlossen — und die Realität in der Codebasis hat sich dann ganz anders entwickelt. Andere RfC wurden erst mal auf „noch mehr Arbeit erforderlich“ gestellt — was in jedem Fall realisitischer ist, denn in der Regel ist ein weiter Weg notwendig, um dieser Vision auch nur nahe zu kommen. Diese RfC müssen also explizit von mir neu beurteilt werden +

+ + + + + + + + + + + + + + + + + + + + +

+ Diese RfC gibt es in verschiedensten Formen, von einer kurz hingeworfenen Idee bis zu einem elaboriert ausgearbeiteten Konzept. Allen gemeinsam ist, daß man sie alsbald beiseite geschoben hat, da den Entwicklern eigentlich von Anfang an klar war, was für ein weiter Weg vor uns liegt. Diese RfC können getrost liegen bleiben, so wie sie sind. +

+ + + + + + + +

+ Diese RfC sind allesamt mit Konflikten verbunden, und wurden nur deshalb formuliert, weil der Initiator schon ahnte, daß es Widerstand gegen diese Idee geben würde. Hier kann man zwei Klassen beobachten +

+
    +
  • + einige RfC sind so verschwurbelt, daß ohne Kenntnis der damaligen Situation überhaupt nicht erkenntlich ist, worum es überhaupt geht; diese RfC wurden meist sehr kontrovers diskutiert, bisweilen sogar per Winkelzug durchgeprügelt und als Konsens dargestellt. +
    • +
  • + die sonstigen RfC dieser Art sind extrem elaboriert geschrieben, so daß man eigentlich nichts mehr dagegen sagen kann; verräterisch ist nur, daß der Diskussionsteil komplett fehlt, oder nicht ernst gemeint ist. +
    • +
+

+ Der Beschluß-Status dieser RfC ist fragwürdig. Tatsächlich wurde über alle diese Vorschläge eine faktische Entscheidung von mir getroffen, indem ich eine Richtung eingschlagen habe, die ich für richtig halte und begründen kann. Die notwendige Diskussion mußte ich dazu mit mir selber führen und ein formaler Beschluß war nicht mehr möglich. Im Ergebnis sind nun praktisch alle charakteristischen Vorschläge von Christian von mir verworfen worden und die allermeisten meiner Vorschläge wurden weiterentwickelt und dabei jedoch substantiell verändert. Insofern ist für diese RfC eine Klarstellung notwendig +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ Der eigentliche RfC schlägt nur vor, Lua zur verbindlichen Scriptsparche zu machen, und C-Bindings einzurichten. Die Kommentare ergeben dann aber, daß Christian diesen RfC sehr wohl im Zusammenhant mit seiner Plugin-Vision gesehen hat, und tatsächliche alle internen Interfaces öffnen und von Lua aufrufbar machen wollte. +

+

+ +

+

+ Dieser Zusammenhang haftet dem RfC nun an, und auch meine Ablehnung stellt darauf ab ⟹ es ist nicht sinnvoll, diesen RfC zu „reparieren“ +

+ + + + + + + + - - + + + @@ -163348,6 +164092,99 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + +

+ ...das ist vermutlich ein Fehler in der MoinMoin-2-Asciidoc-Konvertierung gewesen: viele Diskussionsbeiträge beginnen mit einem "--", was von Asciidoc u.U. als Beginn eines »delimited block« interpretiert wird +

+ + + + + + + + + +

+ ...wodurch sie Asciidoc nicht erkennt, sondern dem vorhergehenden Absatz zuschlägt +

+ + + + + + + + +

+ ...das geht vermutlich zurück auf das Moin-Moin-Wiki von Cehteh: Dort war es üblich, Stichworte mal vorsorglich als Link zu schreiben; in wiki-typischer Weise wurden daraus dann nicht-existente Seiten, die man sukzessive erstellen konnte. Duch die automatische Umwandlung in Asciidoc sind daraus leider sehr viele Links nach dem Muster link:blablubb[]  enstanden. +

+ + + + + + + + + + + + + + + + + + + + +

+ ...die dann aber dem gekennzeichneten Inhalt widersprechen können +

+ + + + + + + + + +
+
+

+ After a talk on IRC ichthyo and me agreed on making lumiera a multi language +

+

+ project where each part can be written in the language which will fit it best. +

+

+ Language purists might disagree on such a mix, but I believe the benefits +

+

+ outweigh the drawbacks. +

+

+
+ +

+

+ ct:: '2007-07-03 05:51:06' +

+

+ +

+
+
+ + + + + @@ -163358,6 +164195,11 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + + +