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.
19 lines
935 B
Text
19 lines
935 B
Text
Extending the Application
|
|
=========================
|
|
|
|
During the inception phase, the link:/x/rfc/AllPluginInterfacesAreC.html[idea was commended]
|
|
to bootstrap the application as a multi-lingual compound of plug-ins, for maximum flexibility
|
|
and ease of contribution. Although this approach garnered much support initially, the ensuing
|
|
discussions questioned its viability, with well-known plugin-based systems and frameworks
|
|
cited as cautionary example.
|
|
|
|
A prototype implementation
|
|
(-> link:PluginBrainstorm.html[draft for the plugin interface])
|
|
was nevertheless developed, but it proved problematic in practical use.
|
|
The goal of a flexibly expandable application is still maintained,
|
|
but the path to achieving it should be based on actual requirements.
|
|
|
|
Development of an https://issues.lumiera.org/ticket/1212[Extension Concept #1212]
|
|
was thus placed on the list of medium-term
|
|
https://issues.lumiera.org/report/17[»Focus Topics«]
|
|
|