Clojurians Log v2

@yogthos There is a particular situation about the indexes which requires some more thinking. Supposing that we have a subscriber which is listening for changes in a :users list at the index 3. Now, there is a change which inserts an element at the index 3 of that list. What should we tell the subscriber? 1. Nothing because it is not the element it was interested in. 2. We tell it about the new value because the subscriber was interested at the value at the index 3 specifically.

The answer to this question depends on what the subscriber wants. I am thinking about having some more options in the subscribe-on-path function to let the user express exactly what s/he wants in the case of indexes. But before I do that, I would like to see how the index-based subscriptions are really used by the template (which I did not implement yet), so I will leave it as it is now and will be back on those issues later.

Additionally, when a diff removes or inserts elements in a vector, the indexes of the subscribers in the subscriber-tree need to be updated. Since the subscriber is registering/unregistering via a path, it creates a problem which I will need to solve at some point.

Intuitively, I think that if the element in the template … 1. is accessed via (-> global :users 3), then the subscription wants that specific index’s content. 2. is accessed via a for block, then the subscription should track an element’s identity and not its position in the list.

One solution would be to have a index translation table near the children hashmap which keeps track of the registered key and the current key.

I think in cases where the indices change, the subscription should get updated as well since it's tracking a particular piece of data

I agree, but if the user explicitly want (-> global :users 3) and we prodive (-> global :users 4) , s/he won’t be happy.

I think that this issue can be resolved later, when the full stack of Vrac starts to work. We will know more at that time.

Right now, I am fixing the documentation.

Documentation updated - https://github.com/green-coder/vrac/blob/diy-furry/doc/prototype-v2.md

For the graph of compute nodes, here is my (non-optimized) plan: 1. Each compute node’s update function should return a diff. Vrac will use that diff and apply it on the node’s old value to get the new value. 2. Each compute node’s update function should accept (for each of its inputs) a diff, an old value and a new value. 3. Each update function has to be pure.

Thanks to the subscriber-tree , each node have the list of its dependent nodes. Each compute node should also have the list of its inputs, so it can unsubscribe on them later, even if it sounds like a redundant. I will reorganize/optimize it later.

Maybe I can have a hash-map dependent-compute-node -> subscribed-path-list next to the subscriber-tree in each node, to make the unsubscribing simpler.

I think that the canonical path feature that I mentioned a few days ago can be resolved at the level of the template’s data model. No need anything special in the compute node for now.