From eda6f1fa7bd7f1d748ccab2762326e9b9d45ed34 Mon Sep 17 00:00:00 2001
From: Daniel K Lyons <dlyons@nrao.edu>
Date: Mon, 8 Feb 2021 16:13:13 -0700
Subject: [PATCH] Thinking more about future products
---
shared/workspaces/workspaces/ARCHITECTURE.md | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/shared/workspaces/workspaces/ARCHITECTURE.md b/shared/workspaces/workspaces/ARCHITECTURE.md
index f6ca0e5f6..243129712 100644
--- a/shared/workspaces/workspaces/ARCHITECTURE.md
+++ b/shared/workspaces/workspaces/ARCHITECTURE.md
@@ -104,3 +104,18 @@ external-execution-block-id future product; it begins life unresolved.
5. The capability system receives the event and matches to the request in the AWAIT PRODUCT state. The step is now
complete and the engine advances the request to the next step.
+
+
+## Notes from call with Nathan
+
+- Capability Request could have type Filesystem -> Filesystem
+- Future Product system could become Product system, adopt responsibility for running the data fetcher or doing copy
+ from earlier request to follow-on request
+- How do we deal with capabilities that do not need files retrieved? They don't have AWAIT PRODUCT at the outset
+- How do we deal with capabilities that ingest or are otherwise final? They still have a working directory at their
+ conclusion which can be used as an input to the next request
+- TODO How do we handle requests that need to fetch multiple things before executing? Restores, for instance,
+ need to retrieve the data AND retrieve the calibration tables? Open question.
+ - Multiple AWAIT PRODUCTs? Or Product System is parameterized by a list of products?
+ - What about follow-ons that also need to request data? Think CIPL -> image
+
--
GitLab