| … | … | @@ -192,6 +192,35 @@ So we're effectively going for version 3, here; lets get it right, |
| 192 | 192 | instead of being half-assed about it. |
| 193 | 193 | |
| 194 | 194 | ### Redesigning layering |
| 195 | So what are the design requirements? |
| 196 | |
| 197 | * We want "views", in that the current AtomSpace is authoritative in |
| 198 | it's contents, hiding/modifying/updating contents that might be in |
| 199 | other remote, attached AtomSpaces. |
| 200 | * So this is not really a "view", per se; it seems to be saying "get rid |
| 201 | of the OverlayFS-like behavior, and provide it in some other way." |
| 202 | * `ProxyNodes` are passive, not active in thier update of AtomSpace |
| 203 | contents. One has to explicitly fetch Atoms, Keys. This prevents the |
| 204 | naive usage of Proxy infrastructure for the hiding/modifying behavior. |
| 205 | * Active updates is not the same as "push notifications". More on this |
| 206 | later. |
| 207 | |
| 208 | Layering has conflicting view/remove semantics. Lets review this: |
| 209 | * The "view" aspect is that everything visible in the current AtomSpace |
| 210 | must actually be in the current AtomSpace, or is visible in a space |
| 211 | below. |
| 212 | * Viewership could be accomplished by copy-in, except that this is |
| 213 | wasteful when a lower layer is in the same RAM. Thus, COW was used. |
| 214 | * Remote proxy viewership has to be implemented as copy-in. This seems |
| 215 | entirely doable with the current BackingStore API. |
| 216 | * The COW implementation also requires hiding, so that a deleted Atom |
| 217 | is marked hidden. |
| 218 | * Local deletion does not create any difficulties when the proxy is |
| 219 | remote. |
| 220 | |
| 221 | The current layering implementation has COW in the current AtomSpace. |
| 222 | Can we push the COW into the proxy, instead? |
| 223 | |
| 195 | 224 | |
| 196 | 225 | ### Are SensoryNode's AtomSpaces? |
| 197 | 226 | By logical extension of the above thoughts, SensoryNodes should be |