Updated Design: Runtime Editor Split (markdown)

Design:-Runtime-Editor-Split.md

@@ -9,7 +9,14 @@ The plan is to break them up into their own discrete packages to provide some mo
    - [Distributed](#distributed)
    - [Scaled](#scaled)
    - [Repurposed Editor](#repurposed-editor)
-   
+ - [Packaging](#packaging)
+   - [node-red-core-runtime](#node-red-core-runtime)
+   - [node-red-core-nodes](#node-red-core-nodes)
+   - [node-red-core-editor](#node-red-core-editor)
+   - [node-red](#node-red)
+ - [Code structure](#code-structure)
+
+
 ## Use Cases
 
 ### Headless
@@ -33,8 +40,6 @@ A device that runs a flow it is given. The flow is edited elsewhere and remotely
  - 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
 
 A node-red flow is edited in one place. When deployed, it gets sent to multiple runtimes to provide horizontal scaling.
@@ -54,20 +59,33 @@ A node-red flow is edited in one place. When deployed, it gets carved up and dif
 
 The Node-RED editor is used for another system entirely that shares the same node/wire visualisation.
 
-## How we're going to do it (to be revisited)
+## Packaging
 
-At the top level, we'll have four npm packages (names tbc)
+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` - the existing package that pulls the above three together, shakes them around, plumbs them together and delivers *exactly* the same experience as it does today (well, hopefully an even better one...)
 
+### node-red-core-runtime
+
+### node-red-core-nodes
+
+### node-red-core-editor
+
+### node-red
+
+## Code structure
+ 
 This is an open question as to whether the git repository should also be split into four along the same lines, or if the release build process would create the four modules from the one repo. There are pros/cons to both.
 
+If we stick with a mono-repo, [lerna](https://lernajs.io/) could be used to manage it - needs some more investigation.
+
 ## Discussion
 
+<details>
 (DCJ) - One of the main items to think about are the UI changes. In the distributed case how is the partitioning of flows done? What attribute says where a particular node should be run? Is it an attribute of a node? Or a group of nodes? or a Tab/Flow? Or should the/a new link node be the thing that distinctly separates parts and holds "location" information for anything it connect to?   
  
 While distributed and scaled are similar, there is one possible distinction that should be highlighted. For the "simple" scaled case the entire flow is sent to multiple runtimes. Is this worth bringing out separately as this may not need any of these UI changes?
-
+</details>