On 08.12.2021 at 19:22, Yannis Guyon via internals wrote: >> On a general principle, I understood that bundling libs should be avoided. > > libavifinfo was designed more as a copy-pastable snippet than a library.
Thanks for clarifying. > Unfortunately AVIF is complex and avifinfo.c is lengthier than expected, > although > I believe 700 lines are still reasonable and way below a library's scale. > >> I am not totally sure aviinfo is stable enough to be bundle either way. > > What would you call "stable enough"? > There is a test > <https://aomedia.googlesource.com/libavifinfo/+/refs/heads/main/tests/avifinfo_test.cc>, > it is currently internally fuzzed > <https://aomedia.googlesource.com/libavifinfo/+/refs/heads/main/tests/avifinfo_fuzz.cc> > and > was successfully run on more > than 60k crawled AVIF images. I do not plan on modifying or testing it > further > until the AVIF format changes. > >> The format will be widely used in a near future so i would rather allow it >> if libavinfo js available rather than bundling it. > > What would be the pros and cons of using a javascript version of libavifinfo > rather than the C one? I think that "js" is a typo, and should have actually been "is". :) Anyhow, that is the point. If there will be no (widely available) libavifinfo, it makes sense to either bundle it, and have the full getimagesize() functionality for AVIF, or to not bundle it, and have only the most basic getimagesize() support for AVIF (as it is now). Christoph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
