-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Idea] Supporting WebP via CocoaPod's subspec #53
[Idea] Supporting WebP via CocoaPod's subspec #53
Conversation
#if TARGET_OS_MACCATALYST | ||
#import <webp/webp.h> | ||
#else | ||
#import <WebP/decode.h> | ||
#import <WebP/encode.h> | ||
#endif | ||
#import <libwebp/decode.h> | ||
#import <libwebp/encode.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this needs to be like this: https://github.com/SDWebImage/SDWebImageWebPCoder/blob/84c97db988a0cc81cf419828bc9606a5a2b26a06/SDWebImageWebPCoder/Classes/SDImageWebPCoder.m#L11-L23
I'm not sure though... Need to dig a little
Thank you for taking active interest! We are committed to having Twitter Image Pipeline be a zero dependency project but have taken great pains to provide abstractions so that consumers can plug in their own customizations. It is important that the I think the I can empathize with the in-between-ness of where does such a "glue" layer live in open source. We have a similar problem between Twitter Image Pipeline and Twitter Network Layer. Using TIP & TNL together requires a small amount of "glue" and we provide that as a gist: https://gist.github.com/NSProgrammer/6e4c93ca9b9518178c9cbc7d950efd9c --- perhaps we need to think more about "glue" being open sourced but that is what we have for now. Were you to construct your own "glue" gist, we would happily link to it. Again, thank you for your PR and great thoughts on advancing Twitter Image Pipeline. Although this PR doesn't align with the philosophy of this project, we hope that you would continue to maximize TIP for your use cases and provide PRs of improvement in the future too! Feel free to reach out for questions or comments on this or any other Twitter iOS open source projects on Twitter: @NolanOBrien |
Also, I should note, that in the upcoming release of TIP, the codec protocol interface will be revised slightly. Adapting to the changes will be very straightforward, but I feel it only fair to prepare you so that you won't be caught off guard that any custom codecs will stop compiling after updating to the latest TIP in the future. |
Thanks @NSProgrammer for such a detailed explanation, I imagined that something like this might be the case so no worries at all! We're more than happy to bring the custom codec under our control so will do just that given your reasoning here I agree with you regarding the glue logic and that was my main reasoning for thinking about how it could be included since the codec itself was already checked into this repo, but it makes sense not to do that because of the libwebp dependency like you mentioned. The idea of using a subspec though was inspired by libraries such as Firebase where their frameworks integrate with one another using subspecs so in theory something similar might be possible here where there is a 'TNL' subspec in this repo that contains the glue code you linked in the gist ... That kind of approach might help consumers who look to use both dependencies 🙂 Thanks again for all the work that went into this, I'll close this PR off now 👍 |
Hey! First off, I only recently discovered this library and wow it's impressive! As our project has evolved we've outgrown our existing tool used for managing remotely served images and when I came across TIP it seemed to check all of the boxes for what I was looking for!
We currently also depend on WebP support and I understand why you didn't include it built into TIP however I was wondering if there is any reason not to provide the Codec via an opt-in subspec using CocaPods?
I see that there is a bit of trickery around getting
libwebp
building for Mac Catalyst however I stubbed across SDWebImage/libwebp-Xcode and it appears to handle all platforms correctly (although I need to double check that). In the sample PR here, I've added a simple subspec that includes theTIPXWebPCodec
as well as a dependency on thelibwebp
pod provided by the linked repo and can confirm that this works for my iOS project... Is this approach something that interests you?I guess that there are still a few unresolved questions though but I wanted to get opinions before I dig deeper:
TIPXWebPCodec
up to scratch to release alongside (I noticed a couple of TODO's)TIPImageCodecCatalogue
or leave that up to the user?No worries if this isn't something that you want to support in TIP, I just thought that it's better to check here as I'd much rather help give back a little than just integrate something directly into our project 🙏