| … | … | @@ -222,15 +222,22 @@ The current layering implementation has COW in the current AtomSpace. |
| 222 | 222 | Can we push the COW into the proxy, instead? |
| 223 | 223 | |
| 224 | 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 |
| 225 | and this is implemented by delegating all access to the indicated |
| 226 | 226 | StorageNode (which would typically be a ProxyNode, to avoid duplication |
| 227 | 227 | of concepts and logic). Questions: |
| 228 | 228 | |
| 229 | | * Is it caching? E.g. does every request for `get-oncoming-set` go out |
| 229 | * Is it caching? E.g. does every request for `get-incoming-set` go out |
| 230 | 230 | to the StorageNode, or do we attempt to fulfill that with what is |
| 231 | 231 | in RAM? This exposes the idea that maybe the current ProxyNode |
| 232 | 232 | design w.r.t. caching is incomplete!? |
| 233 | 233 | |
| 234 | Hmm. What are the differences between the AtomSpace C++ API, and the |
| 235 | BackingStore API? Can we forward every (almost every) AtomSpace call |
| 236 | to the BackingStore? As I currently imagine, the answer is yes. |
| 237 | |
| 238 | To what degree can the AtomSpace and the BackingStore API's be |
| 239 | consolidated into one? |
| 240 | |
| 234 | 241 | |
| 235 | 242 | ### Are SensoryNode's AtomSpaces? |
| 236 | 243 | By logical extension of the above thoughts, SensoryNodes should be |