Updated Design: Runtime Editor Split (markdown)

Design:-Runtime-Editor-Split.md

@@ -24,59 +24,97 @@ The plan is to break them up into their own discrete packages to provide some mo
 ## Use Cases
 
 ### Headless
-
+<details>
 A device that runs a flow it is given. The flow is edited elsewhere and remotely pushed to the device (or hardcoded on the device).
 
  - don't want the overhead of the editor that isn't going to be used
  - supports http endpoints (just doesn't have full editor capability)
 
+</details>
+
 ### Multi-user, single-tenet runtimes
+<details>
 
  - A single hosted instance of the editor is backed by multiple runtimes - one per user or group of users
  - The user access the editor and the underlying api requests are proxied to the appropriate runtime
  - Authentication is handled at the proxy layer
  - API requests can be proxied unmodified (other than auth tokens)
 
+</details>
+
 ### Multi-user, multi-tenet runtimes
+<details>
 
  - A single hosted instance of the editor is backed by multiple runtimes.
  - The user access the editor and the underlying api requests are proxied to the appropriate runtime.
  - Each runtime may host flows of different users that should not see each other
  - The proxy layer provides a filtered view of the flow to ensure the editor only displays information available to the logged in user.
 
-### Scaled
+</details>
 
+### Scaled
+<details>
 A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling.
 
  - Custom actions are added behind the deploy action
  - Serves up the editor without a local version of the runtime
 
-### Distributed
+</details>
 
+### Distributed
+<details>
 A node-red flow is edited in one place. When deployed, it gets carved up and different parts are pushed to different runtimes, either local or remote.
 
  - Custom actions are added behind the deploy action
  - Serves up the editor without a local version of the runtime
-
+</details>
 
 ### Repurposed Editor
-
+<details>
 The Node-RED editor is used for another system entirely that shares the same node/wire visualisation.
+</details>
+
+---
 
 ## Packaging
 
 At the top level, we'll have N npm packages (names tbc)
 
- - `node-red-core-runtime` - the core runtime of Node-RED
- - `node-red-core-nodes` - the default set of nodes in the palette
- - `node-red-core-editor` - the editor component
+ - `@node-red/runtime` - the core runtime of Node-RED
+ - `@node-red/core-nodes` - the default set of nodes in the palette
+ - `@node-red/editor` - the editor component
  - `node-red` - the existing package that pulls the above packages together and delivers *exactly* the same experience as it does today
 
-### node-red-core-runtime
+### @node-red/runtime
 
-### node-red-core-nodes
+### @node-red/core-nodes
 
-### node-red-core-editor
+Moving the core nodes into their own repository poses some challenges in how they get loaded.
+
+#### Current core node load mechanism
+
+1. In the current code, the runtime starts at the path identified by `settings.coreNodesDir` and scans for js/html file pairs. `coreNodesDir` defaults to the `nodes` directory of the node-red module. It also walks up the tree from this directory looking for `node_modules` directories to scan.
+
+2. The scan of the core nodes happens before the scan for node modules - so the core nodes are guaranteed to appear first in the palette.
+
+3. The files are loaded as part of the `node-red` module namespace and there are various hardcoded shortcuts taken with the `node-red` namespace.
+
+4. A single message catalog is registered that covers all core nodes - rather than one-per node-set as is the requirement for nodes loaded from modules.
+
+#### Changes needed
+
+1. have a mechanism to prioritise loading of `@node-red/core-nodes` to ensure node ordering
+2. handle the migration case where `node-red` disappears from the list of nodes - if the auto-reinstall option is enabled (such as in IBM Cloud), we really don't want this to trigger a re-install as we know the nodes are being provided elsewhere
+3. Either:
+    1. split up the message catalog to match the current file name scheme required of modules
+    2. allow a node module to declare a single message catalog that is loaded for all nodes in the module
+4. Many nodes expect their message catalog namespace to be `node-red`. Need to either handle this as a special case, or update all the nodes to the correct catalog. Even then, there are 3rd party nodes that will be using `node-red:common.*` messages that must not change.
+
+
+
+
+
+### @node-red/editor
 
 ### node-red