Handling updated images on static URLs about ios-twitter-image-pipeline HOT 3 OPEN

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.

from ios-twitter-image-pipeline.

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 😅

from ios-twitter-image-pipeline.

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.

from ios-twitter-image-pipeline.