...
No easy way to extend OpenSCD-core Core e.g.
- No options to run code in the background if a solution requires this
- No way to introduce new functionality without making a stable API for all plug-in authors / no easy way to experiment
- Minimize the risk of forking (since OpenSCD-core is apparently missing functionality)
...
- Connecting it to a monitoring system agent (e.g. Elastic APM)
- Single sign-on (user authorization)
...
Decision
The use of OpenSCD addons
...
OpenSCD addons will be a replacement for current mixins, so there is no/less need to fork OpenSCD-Core and to build mixins on top of the fork. Addons allow experiments with (potential) new core functionality. Succesful addons can be merged into OpenSCD-coreCore.
| Info | ||
|---|---|---|
| ||
Example: Wizarding API is hard to make pefect in the first run. If started with an addon for wizarding, we can experiment/use it. If it turns out that the addon is missing crucial functionality. We can introduce a new add-on addon next to the old addon (with its limitations). |
...
If we want OpenSCD to be extendable, we should allow OpenSCD to support `addons`. An addon is like a pluginplug-in, but without the requirement of needing to extend from `HTMLElement`. An `addon` `add-on` is a default exported function from a file.
an `addon` function gets the `OpenSCD` class as a parameter. from From here, it can fetch the document if needed. it It can also subscribe to events dispatched to `open-scd`.
By implementing addons, we can minimize the risk of people forking OpenSCD and adding new functionality. If people want extra functionality on OpenSCD, they can create an addon for it.
...
When `addons` or `background plugins` plug-ins` are supported, it will be possible to migrate current mixins from OpenSCD into `addons` or `background plugins`plug-ins`.
An `addon` is a function that's not depending on anything. The `addon` function gets the `OpenSCD` instance class as a parameter.
Once a Add-on addon is used a lot and considered stable, it could become a part of OpenSCD-core Core itself.
Alternatives
Background pluginplug-in
Another option is to support a new kind of pluginplug-in, `background` pluginsplug-ins. These plugins plug-ins are rendered upon document load, like the `menu` pluginsplug-ins. Except these plugins plug-ins are not shown in the UI. These plugins plug-ins use the dom for dependency injection.
Pros
- It can use the current `plugin` `plug-in` mechanism to load.
Cons
- A background plugin plug-in is extending from `HTMLElement` but it's not rendering anything. This goes against the `CustomElement` principles.
- The dom can get polluted quickly by creating background pluginsplug-ins
Other alternatives: OpenSCD-core addon's alternatives
...
Consequences
- `Addons` need to be loaded apart from `plugins` `plug-ins`
- Risk of having addon's with similar functionality
...