{imp1:1} The engine is to be implemented as a plain C89 lib with an optional, low level CLI frontend tool.
{imp1:2} Dependencies of the engine should be limited to libs reasonably small (e.g. no glib).
{imp1:3} The engine needs to provide an API for user scripting; this API will be fungw.
{imp1:4} The engine must implement all the essential plugins in C89. These are called the core plugins. Scripting is for users; the official core must not depend on any particular scripting language. Rationale: this helps lowering the compilation/installation barriers by avoiding largish external dependencies. This also means it is possible to create a sch-rnd project that can be loaded by any other sch-rnd user - the only requirement is that such a project may depend only on core plugins.
{imp1:5} The frontend, especially GUI editors will be implemented in a similar modular approach. Plugins and user scripting included. Just like pcb-rnd, the GUI editor shall have an API so that the actual GUI implementation is provided by a replaceable plugin. The reason the design document is not verbose about this is that the design document needs to concentrate on the concept, not on the actual implementation. Modularity of the engine is very important for the concept to work properly, while similar implementation details on the UI side won't affect the concept too much.
{imp1:6} The design document calls the central building block engine. Speaking in geda terms, this component is similar to both gnetlist and to libgeda. I wanted to avoid calling it lib because it will also provide a CLI. I wanted to avoid calling it netlist because I believe netlist is only a subset of transport formats/concepts it needs to do between the components.
{imp1:7} The usual "technology" section. For developing the official implementation of sch-rnd I will use the technology already proven useful in pcb-rnd:
{imp1:8} Ripple annotation: as the arrows on the data flow drawing shows, I imagine there would be a lot more flows in a lot more directions. I would like to make these flows natural, not making difference between "forward" and "backward" annotation. This also means the role of the schematics within a project needs to be reconsidered: it's not always the Final Source of All Data. Sometimes parts of the schematics is generated. Sometimes the schematics is the slave, the output to connector pin swapping happening during PCB layout or parameter tuning happening in simulation and the source of data is somewhere else. In a typical use case in the first phase of the project most data would obviously flow from schematics to somewhere-else. But in later phases of the project this bias could change. The only important thing is that by the end of the process, all data (schematics, simulation, pcb, etc.) must be consistent.