Skip to content

docs(API): remove plugin management #35

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ca-d
Copy link

@ca-d ca-d commented Apr 23, 2025

Background

API.md is documenting the plugin-facing API of OpenSCD core and is not related to how a distribution might use OpenSCD core. We hope to keep this plugin-facing API stable (i.e. to only undergo fully backwards-compatible changes) for as long as we can. Broadly, the change we're suggesting here has two goals:

  1. reduce the surface of the API to what is actually needed by plugins, and
  2. remove incidental information which is actually only relevant to potential distributors, not to plugin authors

In order to reach these goals, we propose the following

Changes

File name and preamble

  • rename the file from API.md to docs/API.plugins.md, to more clearly indicate its purpose
  • append "for plugins" to the heading
  • remove any information regarding how plugins are loaded and registered, allowing the distribution to freely choose how to register their plugin custom elements
  • remove the distinction between "menu" and "editor", because placement of the plugin is the distribution's concern

Properties passed to plugins

  • remove editable, because which file types can be edited is the distribution's concern
  • change editCount: number to docVersion: unknown as the community has already agreed on
  • remove plugins and history
    Since we will be removing the ability for plugins to configure plugins (see below), the plugins property is no longer needed for that purpose. We hope to fulfill the second purpose of allowing plugins to amend edits by other plugins with the proposed Transactor API by means of its past and squash properties.

Configuring plugins

We removed the entire section on ConfigurePluginEvent. Its main purpose was to enable a "plugin manager" / "app store" plugin which is needed in the community edition, but would be an active disadvantage in most other distributions (e.g. vendor tools and system operator's internal distributions). We therefore propose to handle this requirement at the distribution level. We at OMICRON, for example, would intend to provide a fully static version of OpenSCD core with no run-time extensibility as a base, and to provide a thin wrapper around that which does dynamic loading of plugins and provides an "app store" experience to the user.

This way we keep the API surface minimal and don't needlessly restrict OpenSCD core implementations or distributions for the time being. If another different use case for allowing plugins to configure other plugins should arise in the future, we can always extend the API to include this facility again.

Minor adjustments

  • fix typo Edit -> EditV2
  • add a monospace font to the CSS variables
  • remove the comment on who is expected to load fonts, since this is a distribution concern

Potential further changes

As the need arises in the future, we might

  • add a customProperties: Record<string, unknown> property to allow a distribution to pass further information to plugins which support it
  • add a Transactor API based transactor: Transactor<EditV2> property

@ca-d ca-d force-pushed the docs-api-remove-plugin-management branch 6 times, most recently from 50a267f to e0b440c Compare April 24, 2025 06:58
@Sander3003
Copy link

As discussed yesterday Jakob Vogelsang likes have have this file maintained somewhere else (e.g. OpenSCD organsiation).

Copy link

@danyill danyill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Might be nice to mention why history is being removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants