Well then we should start arguing about how to implement this feature
My original was proposal was to have the cache TTL configurable from the site config. However, I quite like the idea I implemented with getCachedJSON
that different types of API calls may have their own TTL.
Actually, I think both are complementary ideas. In my opinion, we should be able to say from the templates for how long we’d like the content to be kept, but a setting in the site config should be able to override this, providing a maximum TTL (“refresh my cache every X seconds” type of setting) for both getCachedJSON
and getJSON
.
Please note that in my implementation, giving getCachedJSON
a TTL of 0 means the file is always refetched, because when you call it again, more than 0 seconds has passed since arriving in the cache.
That means if the maximum cache TTL setting is enabled, we can use getJSON URL
to cache the content for a certain time, or getCachedJSON 0 URL
to have it always fresh. And in any case, if --ignoreCache
is passed, fresh content is always fetched.
I think such a system would allow for enough flexibility : not caching content indefinitely, and allowing per-template fresh/cached content.
Actually, I’m wondering if caching “indefinitely” (that is, until --ignoreCache
is passed) is a bug or a feature. Maybe that would be worth another function like getPermanentJSON
for when we know the content is not going to change?