Proposal: deeper cache searches

[vreuter]

Sometimes I forget the subfolder to which I wrote a cache. Or even if not, I've explored the filesystem and have found the name that I want. Now I want to loadCaches() it. "Uh-oh...I need to successfully reconstruct the path to the folder that cache is inhabiting, relative to my RCACHE.DIR! Wait...what's my RCHACHE.DIR?! Calling getOption...that's just too much to handle."

Anyway, fun hypotheticals aside, it'd be cool to have some parameter like recursive (maybe even defaulting to TRUE) to allow simpleCache to explore the hierarchy rooted at RCACHE.DIR. listCaches() could implement this, and then simpleCache and loadCaches could call into that.

• add deeper capability to listCaches
• call into listCaches from loadCaches
• call into listCaches from simpleCache (though possibly precluded by how loadCaches failure message #20 is handled)

[vreuter]

Ah, also linked to #15!

[nsheff]

wait, why can't you just pass cacheSubDir to loadCaches?

we can't have simpleCache loading caches from other subdirs, since we use subdirs as a kind of namespace to separate caches that may have the same name.

but yes, listCaches should show subdirs (per #15) and it could also display RCACHE.DIR.

[vreuter]

I could, but that's the "I need to successfully reconstruct the path to the folder that the cache is inhabiting" part. No big deal if the subfolder is within the RCACHE.DIR itself, but if the subfolder is multiple layers deep, it seems tedious to force the user to reconstruct it.

If we make listCaches do something akin to find <value-of-RCACHE-DIR> -name "*.RData", that operation would contain the complete set of cache names available. If just a name's passed, then there would be an error if there's a collision, but if not, then the uniquely-matched cache file would be used (or an error or whatever if there's no match at all).