Doc: Core, Bedrock and Distribution layers #1
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| # 1. Record architecture decisions | ||
|
|
||
| Date: 2025-04-10 | ||
|
|
||
| ## Status | ||
|
|
||
| Accepted | ||
|
|
||
| ## Context | ||
|
|
||
| We need to record the architectural decisions made on this project. | ||
|
|
||
| ## Decision | ||
|
|
||
| We will use Architecture Decision Records, as [described by Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions). | ||
|
|
||
| ## Consequences | ||
|
|
||
| See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's [adr-tools](https://github.com/npryce/adr-tools). | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,40 @@ | ||||||
| # 2. Core, Badrock and Distribution as base layers of OpenSCD | ||||||
|
|
||||||
| Date: 2025-04-10 | ||||||
|
|
||||||
| ## Status | ||||||
|
|
||||||
| Accepted | ||||||
|
|
||||||
| ## Context | ||||||
|
|
||||||
| As a community we would like to have a stable and UI technology agnostic API to use in our plugins and build on top of it. | ||||||
| Current, the name "OpenSCD Core" can lead to misunderstandings. It not only contains and API but it provides a ready-to-go UI, the plugin loading mechanism and other things. | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| However, we still need an API and specification, and a a quick way to create and configure a new distribution of OpenSCD. | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## Decision | ||||||
|
|
||||||
| We will split up OpenSCD Core by its focus and target groups: | ||||||
|
|
||||||
| ```txt | ||||||
| ┌──────────────────────┐ | ||||||
| │ Distribution │ | ||||||
| └──┬────────────────┬──┘ | ||||||
| │ Bedrock │ | ||||||
| └──┬──────────┬──┘ | ||||||
| │ Core │ | ||||||
| └──────────┘ | ||||||
| ``` | ||||||
|
|
||||||
| 1. Distribution: It is for distributors who want to create a new instance of OpenSCD and tailor it for specific needs through possible configurations. | ||||||
|
There was a problem hiding this comment. What is in a distribution - is it just a collection of plugins built on top of bedrock or is it more? Does it include bundling/packaging? Should we show plugins here in relation to a distribution? I feel they should be in this diagram somewhere... ```txt
┌──────────────────────┐ ┌─────────┐
│ Distribution │<--│ Plugins |
└──┬────────────────┬──┘ └─────────┘
│ Bedrock │
└──┬──────────┬──┘
│ Core │
└──────────┘ |
||||||
|
|
||||||
| 2. Bedrock: You can use a given Bedrock to build your own OpenSCD distribution. It is a Web Component that you can easily deploy and configure. If you need more or different functionality that you cannot achive by configuring a Bedrock, you can create your own. | ||||||
|
There was a problem hiding this comment. Can we describe what is in bedrock with some concrete examples? For instance:
Does it also include
|
||||||
|
|
||||||
| 3. Core: it is mainly for plugin-, bedrock- and distribution developers in the ecosystem to help each other create plugins that are compatible with every distributions and also to create distributions that are compatible with most of the plugins. | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
|
|
||||||
| ## Consequences | ||||||
|
|
||||||
| - With the new, simpler Core we can agree on the common API on the code level | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| - Other components and layers are not bound to a specific UI technology | ||||||
| - We aggre on what belongs into the core | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| - We have to create a new bedrock with the extracted core functionality | ||||||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get more and more lost even I thought I finally got an overview. Important for me would also be for which repositories this ADR's are made/responsible.
In short, till now I referenced always one of following ADR's locations for OpenSCD:
Maybe we can also add an explanation how this existing ADR's are related to this ADR's here? Do this ADR's replace them? Should we collect all ADR's for all repositories in the documentation repository (https://github.com/openscd/Documentation)? Just some ideas ...