| … | … | @@ -61,21 +61,21 @@ external object. |
| 61 | 61 | |
| 62 | 62 | But first, a distraction: |
| 63 | 63 | The `ExecuteThreadedLink` gathers results into a QueueValue. The |
| 64 | | `ParallelLink` fires and forgets: it runs threads, dettaches, does |
| 64 | `ParallelLink` fires and forgets: it runs threads, detaches, does |
| 65 | 65 | not wait for completion; does not collect results. Also does not specify |
| 66 | | max-threads to use (because doing so des not seem to make sense, if |
| 66 | max-threads to use (because doing so does not seem to make sense, if |
| 67 | 67 | one is not going to wait?) |
| 68 | 68 | |
| 69 | 69 | ### Execute ... where? |
| 70 | 70 | What should the argument to `PureExec` be? Currently, it allows an |
| 71 | | AtomSpace to be specified. If none specfied, an anonymoous temporary |
| 71 | AtomSpace to be specified. If none specified, an anonymous temporary |
| 72 | 72 | child AtomSpace is used. Otherwise, it is implicitly assumed that |
| 73 | 73 | the specified AtomSpace inherits from the current AtomSpace, as |
| 74 | 74 | otherwise, bad things are likely to happen. Untested: what does it |
| 75 | 75 | even mean to execute "somewhere else"? |
| 76 | 76 | |
| 77 | 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" |
| 78 | copied to the remote location. (This is not needed when the "remote" |
| 79 | 79 | location is a child of the current AtomSpace) |
| 80 | 80 | |
| 81 | 81 | * There is explicit mechanism for copying Atoms around, other than |
| … | … | @@ -103,11 +103,11 @@ for reading is also accessible for writing (unless it is marked |
| 103 | 103 | read-only.) |
| 104 | 104 | |
| 105 | 105 | The current implementation of layered AtomSpaces has some strong |
| 106 | | negative performance reprecussions. This is because the layers are |
| 106 | negative performance repercussions. This is because the layers are |
| 107 | 107 | envisioned as being OverlayFS-like: Atoms in lower layers can be masked |
| 108 | 108 | or hidden in higher layers, so that it looks like they are absent. |
| 109 | 109 | Atoms in higher layers can have different key-value store contents |
| 110 | | than lower layers. The lookup has fairly strongly noticable performance |
| 110 | than lower layers. The lookup has fairly strongly noticeable performance |
| 111 | 111 | impacts, even though this is not benchmarked at this time. |
| 112 | 112 | |
| 113 | 113 | This directed graph is represented with a Frame, which is an Atom that |
| … | … | @@ -135,7 +135,7 @@ elevates a StorageNode (this time, in the form of a Proxy) to be at the |
| 135 | 135 | same conceptual level as the AtomSpace. So we now have three distinct |
| 136 | 136 | "remote" operations: read, write and execute. |
| 137 | 137 | |
| 138 | | ### Reinventing Cmputing? |
| 138 | ### Reinventing Computing? |
| 139 | 139 | The `rwx` certainly make it feel like we're re-inventing computing. |
| 140 | 140 | Lets take a closer look and make sure we are not missing anything. |
| 141 | 141 | |
| … | … | @@ -159,14 +159,14 @@ Lets take a closer look and make sure we are not missing anything. |
| 159 | 159 | * The actual devices hanging off the end of channels are disk drives, |
| 160 | 160 | storage clusters, connected via fiber channel, ethernet, etc. The |
| 161 | 161 | notable difference here is that topology configuration happens at |
| 162 | | a differrent software abstraction level then the hardware: The |
| 162 | a different software abstraction level then the hardware: The |
| 163 | 163 | sysadmin gets a GUI dashboard with blinkenlights and knopkes. |
| 164 | 164 | The programmer implementing the GUI gets a stack of libraries, |
| 165 | 165 | each working at different abstraction layers. At this time, there |
| 166 | 166 | is no comparable stack of interfaces for Atomese, so I don't extract |
| 167 | 167 | any wisdom, here. |
| 168 | 168 | |
| 169 | | * The Ceph storage cluster offers several lessons. Formost is a negative |
| 169 | * The Ceph storage cluster offers several lessons. Foremost is a negative |
| 170 | 170 | lesson: file ownership and uid/gid management is outside the scope |
| 171 | 171 | of CephFS. This is a holdover from Unix: uids and gids are numeric; |
| 172 | 172 | the correlation to actual user accounts in `/etc/passwd` and |
| … | … | @@ -179,7 +179,7 @@ Lets take a closer look and make sure we are not missing anything. |
| 179 | 179 | crypto key for the particular action to be taken. |
| 180 | 180 | |
| 181 | 181 | * On the topic of crypto, we have the idea of smart contracts, where |
| 182 | | multiple parties can engage in coopertive actions by authenticating |
| 182 | multiple parties can engage in cooperative actions by authenticating |
| 183 | 183 | with crypto keys. |
| 184 | 184 | |
| 185 | 185 | How can we leverage the above for the next-gen design? |
| … | … | @@ -199,7 +199,7 @@ So what are the design requirements? |
| 199 | 199 | other remote, attached AtomSpaces. |
| 200 | 200 | * So this is not really a "view", per se; it seems to be saying "get rid |
| 201 | 201 | of the OverlayFS-like behavior, and provide it in some other way." |
| 202 | | * `ProxyNodes` are passive, not active in thier update of AtomSpace |
| 202 | * `ProxyNodes` are passive, not active in their update of AtomSpace |
| 203 | 203 | contents. One has to explicitly fetch Atoms, Keys. This prevents the |
| 204 | 204 | naive usage of Proxy infrastructure for the hiding/modifying behavior. |
| 205 | 205 | * Active updates is not the same as "push notifications". More on this |
| … | … | @@ -238,6 +238,8 @@ to the BackingStore? As I currently imagine, the answer is yes. |
| 238 | 238 | To what degree can the AtomSpace and the BackingStore API's be |
| 239 | 239 | consolidated into one? |
| 240 | 240 | |
| 241 | ### Recap |
| 242 | |
| 241 | 243 | |
| 242 | 244 | ### Are SensoryNode's AtomSpaces? |
| 243 | 245 | By logical extension of the above thoughts, SensoryNodes should be |
| … | … | @@ -252,8 +254,8 @@ come back from remote sensing... |
| 252 | 254 | |
| 253 | 255 | TODO List |
| 254 | 256 | --------- |
| 255 | | Writiing the above, the TODO list expands: |
| 257 | Writhing the above, the TODO list expands: |
| 256 | 258 | * The ThreadJoinLink should be removed from Atomese. DONE. |
| 257 | | * Benchmark the Atompsace layers/frame performance. Maybe with a variant |
| 259 | * Benchmark the AtomSpace layers/frame performance. Maybe with a variant |
| 258 | 260 | of the `LargeZipfUTest` layout, but this time with different count |
| 259 | 261 | data at each layer. |