| … | … | @@ -66,6 +66,34 @@ not wait for completion; does not collect results. Also does not specify |
| 66 | 66 | max-threads to use (because doing so des not seem to make sense, if |
| 67 | 67 | one is not going to wait?) |
| 68 | 68 | |
| 69 | ### Execute ... where? |
| 70 | What should the argument to `PureExec` be? Currently, it allows an |
| 71 | AtomSpace to be specified. If none specfied, an anonymoous temporary |
| 72 | child AtomSpace is used. Otherwise, it is implicitly assumed that |
| 73 | the specified AtomSpace inherits from the current AtomSpace, as |
| 74 | otherwise, bad things are likely to happen. Untested: what does it |
| 75 | even mean to execute "somewhere else"? |
| 76 | |
| 77 | * The Atoms appearing directly in the PureExec would need to be |
| 78 | copied to the remote locaton. (This is not needed when the "remote" |
| 79 | location is a child of the current AtomSpace) |
| 80 | |
| 81 | * There is explicit mechanism for copying Atoms around, other than |
| 82 | what is provided by `StorageNode` |
| 83 | |
| 84 | * Should remote AtomSpaces be a kind-of StorageNode? Conversely, |
| 85 | perhaps StorageNode should be a kind-of Frame? |
| 86 | |
| 87 | * Currently, remote execution is provided by `fetch-query` in the |
| 88 | StorageNode; presumably this can/should be extended to be any |
| 89 | kind of execution!? |
| 90 | |
| 91 | The above questions envision an extension/mutation of the current |
| 92 | StorageNode concepts to be Frame-like. Which seems like an awesome |
| 93 | idea, as I write this. |
| 94 | |
| 95 | |
| 96 | |
| 69 | 97 | TODO List |
| 70 | 98 | --------- |
| 71 | 99 | Writiing the above, the TODO list expands: |