Created Design: Runtime Editor Split (markdown)

Design:-Runtime-Editor-Split.md

@@ -0,0 +1,35 @@
+Currently, Node-RED is a monolithic entity that has both the editor and runtime packaged in one place.
+
+The plan is to break them up into their own discrete packages that can be used separately.
+
+## Use Cases
+
+### Headless device
+
+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
+
+### Distributed Node-RED
+
+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.
+
+ - Serves up the editor without a local version of the runtime
+ - Custom actions are added behind the deploy action
+
+### Not-RED Editor
+
+The Node-RED editor is used for another system entirely that shares the same node/wire visualisation.
+
+
+## How we're going to do it
+
+At the top level, we'll have four 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...)
+
+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.
+