Handling updated images on static URLs

[joelekstrom]

Hi guys! You published this library very conveniently since we just yesterday started seeing problems with our image caching over at Forza Football. Reading your description, they are similar to yours, and everything this library does seems to fit us very well, so we are evaluating it right now.

However, there is one problem that pretty much every image caching library on iOS suffers from - how to handle updated/outdated images. I would like to ask you if it's possible (or how you would solve) an updated image residing on the same URL as before.

For example, if our servers set a max-age of 3 days - will the library discard the image after 3 days and request a whole new one, even if it's the same image? We sometimes need to update an image on the same URL, so we can't set a too high max age. But we still would like the HTTP-caching functionalities. Ideally, after 3 days, the library would request the image, and if it gets a 304, it just keeps the same image in the cache and refreshes the TTL.

Looking at the process you describe in your README, it seems to me that the library will never attempt to refresh an image if it's already in the cache. Is this true?

[NSProgrammer]

So, to be perfectly honest, I was worried about this use case. Before we ever wanted to build TIP, Twitter took the approach of never reusing image URLs. There are pros and cons to both, but the reuse of image URLs offered far too much complexity and we opted for every image to be unique (with modifiers for size variants of course). When I had written the TIP proposal I had proposed handling the reused image URL problem within TIP but it was eliminated as out of scope right away and we never pursued it. I am sorry that our scope defeats what I'd hoped for this framework as a framework for all use cases.

Given where that leaves us, I think there are a few options for you: 1) try to build a separate layer of code on top of or around TIP to support the use case (really focus TIP on the fetching/caching and you control the aging and reloading). 2) use the features TIP offers to glue something together (such as restricting what caches to hit, using a unique modifier to the real URL and hydrating the URL request being sent, utilizing image previews, using multiple siloed pipelines, using a hacked "alternative cache" and/or having a custom network layer plugged in). 3) fork TIP and see if you are able to add the feature directly.

If you pursued no-3, I would be very open to a PR to add that functionality to TIP but cannot really promise resourcing to support building it end-to-end.

Really sorry about the use case you have not meshing with TIP. I know it's unfair, but no-4 would also be to have the backend change to always use unique URLs.

[joelekstrom]

Thanks for your detailed answer. Yes, I'm starting to see that ideally, all our image URL's should be unique. For the long term, this would save us a lot of headaches. But as always, there will be more pressing matters to focus on, and we will likely need to do correct HTTP caching as well before this.

Meanwhile, we will evaluate each of your suggestions and see if any of them makes it feasible for use to use TIP in our application. I'd love to make a fork and incorporate this in the library somehow. Let's see how much time we can motivate spending on this 😅

[NSProgrammer]

If you do fork, I can recommend looking at keeping things in line with how we do resumable downloads. If a condition is met that you want to check the network for a 304 (unchanged) or a 200 (changed, new bytes), the logic would be very similar to a resumed download, with the minor difference being you have all the bytes already. That's how I was thinking of it anyway.