Updated Design: Palette Management UI (markdown)

Design:-Palette-Management-UI.md

@@ -18,9 +18,37 @@ Secondary considerations
  - modify node loading lifecycle so it only loads 'active' nodes - to maximise memory saving
 
 
+### Catalog API
+
+How a catalog advertises what is available.
+
+Two high-level approaches:
+
+1. catalog url points to a json file that provides the content of the catalog. Returns complete catalog every time. The use of ETags on the request/response can be used to prevent unnecessary transfers. All searching etc is then done on the client side. GitHub pages (now) enables CORS, so we could easily host the file via github.
+
+2. catalog url points to a REST api that can be used to list/pagenate results and do search on the server side.
+
+The former approach is the one taken by the Arduino library ecosystem. It just requires hosting a file (that can be generated via whatever means necessary). The latter is what npm does and would potentially put a much higher dependency and load on flows.nodered.org.
+
+I'm inclined to stick with option 1 - but would welcome feedback.
+
+
+The actual structure of the file is tbd - but must include, for each node:
+ - name
+ - description (short - not full readme)
+ - version
+ - license (?)
+ - ...
+
+
 ### Palette Management UI
 
-### Catalog API
+How the user manages their palette. Three distinct views:
+
+ - enable/disable/remove what they currently have
+ - browse and install available nodes
+ - configure the available catalogs (could be hardcoded in `settings.js` for initial version)
 
 ### Runtime handling
 
+Most pieces should already be in place. Need to review whether there should be a hook into storage to deal with add/remove nodes; so it could maintain a `package.json` file for the user.