lockingcache into its own module

[BHare1985]

I was looking for a locking cache to use on my mapnik tile server, and I found one that will work within this module.

Is it possible to separate out your lockingcache to it's own node module? that way the dependency for the lockingcache is met above tilelive-mapnik. I also think its cleaner to separate the lockingcache out from tilelive-mapnik as its more or less stand alone.

On the topic of caching tiles, I notice you throw out the lockingcache instantly after all blocking requests are completed. Would it be possible to say generate multiple tiles using the metatile cache and keep them in memory for the off-chance they may be re-used.

In particular utf grids for png tiles. There is a chance that a image tile that was generated may want have a grid tile generated over the next X minutes, and so it could keep the source cache for some time. I understand the solution for not regenerating tiles currently is using vector tiles, but I haven't progressed enough to implement that in my stack. Just figured id bring it to attention and perhaps warrant a thought for a few minutes to reevaluate the possibility :)

[brianreavis]

Not to hijack, but I think async-cache fits the bill? It's solid – I've been using it with success on the tilestrata modules. There's also active-cache (a wrapper) if you want to auto-purge.

[BHare1985]

async-cache looks nice. Looking at the documentation for lru-cache I think it can do my ideal caching which is to leave stale items in cache, and then once a stale item is fetched, it will return the stale value but then asynchronously also load the cache with the fresh value in the next tick (thanks to the dispose function of lru-cache).

The only thing async-cache doesnt have that I'd like is a sliding TTL.

I am leaving issue open because I still think the locking cache should be separated out from tilelive-mapnik