| … | … | @@ -82,20 +82,50 @@ even mean to execute "somewhere else"? |
| 82 | 82 | what is provided by `StorageNode` |
| 83 | 83 | |
| 84 | 84 | * Should remote AtomSpaces be a kind-of StorageNode? Conversely, |
| 85 | | perhaps StorageNode should be a kind-of Frame? |
| 85 | perhaps StorageNode should be a kind-of AtomSpace? |
| 86 | 86 | |
| 87 | 87 | * Currently, remote execution is provided by `fetch-query` in the |
| 88 | 88 | StorageNode; presumably this can/should be extended to be any |
| 89 | 89 | kind of execution!? |
| 90 | 90 | |
| 91 | 91 | The above questions envision an extension/mutation of the current |
| 92 | | StorageNode concepts to be Frame-like. Which seems like an awesome |
| 92 | StorageNode concepts to be AtomSpacee-like. Which seems like an awesome |
| 93 | 93 | idea, as I write this. |
| 94 | 94 | |
| 95 | | ### Are SensoryNode's Frames? |
| 95 | ### Frames and Proxies |
| 96 | The layering of AtomSpaces was inspired by `git` and was envisioned as |
| 97 | a directed acyclic graph, with each AtomSpace above inheriting from the |
| 98 | AtomSpaces below. The implicit, unspoken assumption was that all of |
| 99 | these were local, on the same system/RAM, and thus directly accessible. |
| 100 | Because everything is local, another implicit assumption is that both |
| 101 | reads and writes are described by this graph: an AtomSpace accessible |
| 102 | for reading is also accessible for writing (unless it is marked |
| 103 | read-only.) |
| 104 | |
| 105 | This directed graph is represented with a Frame, which is an Atom that |
| 106 | is both like a Node and like a Link, having both a (singular) name and |
| 107 | an outgoing set. |
| 108 | |
| 109 | A completely different layering mechanism is that of the `ProxyNode`, |
| 110 | which is a kind-of `StorageNode`. It replaces the idea of a DAG with |
| 111 | a more flexible system: |
| 112 | |
| 113 | * Reads are distinct from writes; one can be handled, and the other not. |
| 114 | * Dropping writes makes the proxy effectively read-only. |
| 115 | * Read priority and caching are possible. |
| 116 | * Write mirroring and write sharding are possible. |
| 117 | |
| 118 | This suggests that Frames should be replaced by ProxyNodes. Which again |
| 119 | elevates a StorageNode (this time, in the form of a Proxy) to be at the |
| 120 | same conceptual level as the AtomSpace. So we now have three distinct |
| 121 | "remote" operations: read, write and execute. |
| 122 | |
| 123 | |
| 124 | |
| 125 | ### Are SensoryNode's AtomSpaces? |
| 96 | 126 | By logical extension of the above thoughts, SensoryNodes should be |
| 97 | | Frames too ... I guess? But "remote" AtomSpaces are "remote", whereas |
| 98 | | SensoryNodes are local interfaces to that "remoteness". |
| 127 | AtomSpaces too ... I guess? But "remote" AtomSpaces are "remote", |
| 128 | whereas SensoryNodes are local interfaces to that "remoteness". |
| 99 | 129 | |
| 100 | 130 | The inheritance hierarchy gets a bit messy; not all remote things |
| 101 | 131 | have to form of AtomSpaces ... or do they? It's always Values that |