The old way was to manually recreate all children refs/links of a hash.
This required several calls to IPFS via api which was not efficient,
consequently we had 3 cache structures to track it.
Now, all of this offloaded to IPFS which as I learned can do recursive
check for children of a hash/ref in one move. The speed seems to be
about the same, but we drastically simplified the code and
get rid of two unnecessary caches.
We could get rid of the last cache locallyCached as well but it still
gives some speed advantages on consequent calls for IsCached and cache
time is only 5 minutes. Nevertheless, it is something to consider.
The most likely scenario when we need real time updates:
a user pin a file which is remote and eagerly calls brig ls to see
if the status changed. But if it is big file it will probably take a few
minutes anyway, so it is OK to have a bit stale info.
Closes #54
The old way was to manually recreate all children refs/links of a hash. This required several calls to IPFS via api which was not efficient, consequently we had 3 cache structures to track it.
Now, all of this offloaded to IPFS which as I learned can do recursive check for children of a hash/ref in one move. The speed seems to be about the same, but we drastically simplified the code and get rid of two unnecessary caches.
We could get rid of the last cache
locallyCachedas well but it still gives some speed advantages on consequent calls for IsCached and cache time is only 5 minutes. Nevertheless, it is something to consider.The most likely scenario when we need real time updates: a user pin a file which is remote and eagerly calls
brig lsto see if the status changed. But if it is big file it will probably take a few minutes anyway, so it is OK to have a bit stale info.