Context
Current problems:
No easy way to extend OpenSCD-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)
CoMPAS needs a extension in order to allow:
- Connecting it to a monitoring system agent (e.g. Elastic APM)
- Single sign-on (user authorization)
Decision
The use of OpenSCD addons
OpenSCD addons are an extension of OpenSCD-Core to split functionality. This functionality can be pure technical and requires no custom UI. Examples for some OpenSCD addons are Wizarding, Validating, Waiting, etc.
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-Core.
| 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 addon next to the old addon (with its limitations). |
# OpenSCD Core should support Addons
Date: 2023-06-05
## Status
Open
...
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.```
| Code Block |
|---|
export default function xsdValidate(openSCD: OpenSCD) { |
...
openSCD.addEventListener('validate', (evt: ValidationEvent) => { |
...
const { doc } = openSCD; |
...
// Do actual validation to the doc. |
...
}); } |
When `addons` or `background plug-ins` are supported, it will be possible to migrate current mixins from OpenSCD into `addons` or `background 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 addon is used a lot and considered stable, it could become a part of OpenSCD-Core itself.
Alternatives
Background plug-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.
When `addons` or `background plugins` are supported, it will be possible to migrate current mixins from OpenSCD into `addons` or `background plugins`.
## Pros and Cons
- ### Background plugin
#### 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 plugins
### Addons
#### Pros
An `addon` is a function that's not depending on anything.
The `addon` function gets the `OpenSCD` instance class as a parameter.
plug-ins
Other alternatives: OpenSCD-core addons alternatives
Consequences
...
- `Addons` need to be loaded apart from
...
- `plug-ins`
- Risk of having addons with similar functionality