| … | … | @@ -221,6 +221,16 @@ Layering has conflicting view/remove semantics. Lets review this: |
| 221 | 221 | The current layering implementation has COW in the current AtomSpace. |
| 222 | 222 | Can we push the COW into the proxy, instead? |
| 223 | 223 | |
| 224 | The most obvious solution is to create a new type: `PROXY_ATOMSPACE` |
| 225 | and this is implmeneted by delegating all access to the indicated |
| 226 | StorageNode (which would typically be a ProxyNode, to avoid duplication |
| 227 | of concepts and logic). Questions: |
| 228 | |
| 229 | * Is it caching? E.g. does every request for `get-oncoming-set` go out |
| 230 | to the StorageNode, or do we attempt to fulfill that with what is |
| 231 | in RAM? This exposes the idea that maybe the current ProxyNode |
| 232 | design w.r.t. caching is incomplete!? |
| 233 | |
| 224 | 234 | |
| 225 | 235 | ### Are SensoryNode's AtomSpaces? |
| 226 | 236 | By logical extension of the above thoughts, SensoryNodes should be |