benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lumiera_documentation/doc/technical/library/index.txt

71 lines
4.1 KiB
Text
Raw Normal View History

add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Library documentation
=====================
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
Alongside with the core Lumiera Application, and as part of ongoing development work,
a lot of *Library code* is written. Many of this happens on occasion. Library solutions
are frequently ``discovered'', while in the middle of the implementation, driven by the
desire to re-use some code structure that was built just recently and in a similar way.
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
Support Library
---------------
Over time, a huge and growing number of generic building blocks has been collected.
Hoever, not all parts of this collection are equally well maintained and presentable.
It happened time and again that some pattern extracted into the library turned out
to be rather some kind or ephemeral habit -- maybe even a bad habit in hindsight --
and turned into a dead-end eventually. Furthermore, a lot of our library code has
been superseded by very similar features of newer language standards.footnote:[
It seems like developers working on similar problems tend to have similar ideas
to improve productivity. Unfortunately, the solutions resulting from this convergence
of ideas have a tendency not to ``converge'' so well in practical terms.
For example, Lumiera had a tuple type a long time before a mature tuple implementation
was available in the Boost libraries, yet in the end, we could retrofit most of our
tuple-handling library. However, other cases did not play out so well: we evolved
the idea of ``iterators'' to become a lazy processing pipeline, but unfortunately
our design leans more into the direction of functional programming and is much
more expressive and powerful as abbreviation than the »Range-TS« from C++20.
]
The entrance barrier for something to be added to our _Support Library_ is rather low:
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
- extracting it as a library function _must make the client code clearer_
- it must be possible to describe its purpose and its usage in _generic terms_ --
without referring to data types and definitions from our domain models.
- it must be _essentially stateless_ and self-contained
- it must be easy to document with an unit-test.
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
Over time, parts of the Support Library have evolved into some kind of a framework:
Notably the link:{ldoc}/design/architecture/time/index.html[time and timecode] handling,
our link:Dependencies.html[dependency and service handling],
the link:DiffFramework.html[»Diff framework«], together with the recursive property trees
used for link:{ldoc}/design/architecture/ETD.html[»External Tree Description«], the
link:iterator.html[iterator pipeline builders], the metaprogramming helpers for transforming
function signatures and generic sequences, and our collection of string conversion, parsing
and rendering functions. These all turned into distinguishing traits of the Lumiera code base.
The link:{ldoc}/technical/overview.html#_library[»Library« section of the »Overview« document]
contains a long list of short descriptions for relevant features of the Support Library.
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
.how to crack nuts...
[NOTE]
In the how-to section, there is a page with a loose collection of
link:{ldoc}/technical/howto/crackNuts.html[successful solution patterns],
many of which rely on unique features of our Support Lib.
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Application: Adjustments to the Layer structure During the last months, a lot of gradual changes to policies and guidelines had been finalised and documented. Moreover, recent clarifications regarding memory management in the render engine will lead to a clearer definition of the »Vault« Layer's role, with some ''engine code'' expected to move down. On this occasion, I reworked relevant sections in the documentation to confirm the role that now falls to central parts of the overall architecture. Notably I decided to rename those parts related to the application backbone as »Vessel« — to underpin the more active and defining role they assumed.
2026-02-28 22:55:09 +01:00
Interface Library
-----------------
The Lumiera Application is designed deliberately in a way to be controllable by scripts. All of
the Session, the models and the vault are fully operational without the GUI. Any significant
functionality shall be usable through the primary Façade Interfaces alone. Yet in order to create
such an open and extensible application as envisioned, we also need to build up an _interface layer._
Eventually, this should evolve into a binding library for using Lumiera -- however, none of this
interface building work has been accomplished yet, as of 2026. We do not even have a complete
picture how _event sourcing_ meshes together with our UI commands and the configuration rules.
- we still need to identify those select core concepts which need to be exposed
- we need to refactor the corresponding data types to resolve cross dependencies to the implementation
- only then we could think about moving those data types into an _official Lumiera interface_
add a section for library technical documentation
2012-01-08 00:12:54 +01:00
Reference in a new issue Copy permalink