You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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)


Decission


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.


Example

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 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 plugin, but without the requirement of needing to extend from `HTMLElement`. An `addon` is a default exported function from a file.
an `addon` function gets the `OpenSCD` class as a parameter. from here, it can fetch the document if needed. 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.


export default function xsdValidate(openSCD: OpenSCD) {
    openSCD.addEventListener('validate', (evt: ValidationEvent) => {
        const { doc } = openSCD;
        // Do actual validation to the doc.
    });
}

When `addons` or `background plugins` are supported, it will be possible to migrate current mixins from OpenSCD into `addons` or `background plugins`.

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 is used a lot and considered stable, it could become a part of OpenSCD-core itself.



Alternatives

Background plugin

Another option is to support a new kind of plugin, `background` plugins. These plugins are rendered upon document load, like the `menu` plugins. Except these plugins are not shown in the UI. These plugins use the dom for dependency injection.

Pros
- It can use the current `plugin` mechanism to load.
Cons
- A background plugin 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


Other alternatives: OpenSCD-core addon's alternatives


Conserquences

  • `Addons` need to be loaded apart from `plugins` 
  • Risk of having addon's with similar functionality



  • No labels