feat(swagger-ui): cache swagger zip

[thewh1teagle]

Enabled with

cargo build -p utoipa-swagger-ui --features "cache,reqwest"

Resolve #1209 (comment)

[juhaku]

Still needs:

• Update to CHANGELOG.md
• Update docs and README.md

[juhaku]

Maybe I am not educated enough, do we need all that C crap and pointer juggling? Aren't there a better and perhaps more simply way to the the same result or at least similar result?

As I understand this tries to use the users local cache dir for caching the data. I'd rather place it just the OUTPUT dir of the crate in question. Or target dir since the OUTPUT dir can change?

[juhaku]

I'd expect at least some level of documentation what all that black magic does. Whats more is that I can guarantee that there are few that even dare to touch this code and I don't want to maintain this code.

[thewh1teagle]

Maybe I am not educated enough, do we need all that C crap and pointer juggling? Aren't there a better and perhaps more simply way to the the same result or at least similar result?

I also doesn't like that. though it's that expressive because the original dev wanted to support as many platforms as he can. but it's just for caching and I guess windows/linux/macos support is enough so we can simplify it into few lines

[thewh1teagle]

As I understand this tries to use the users local cache dir for caching the data. I'd rather place it just the OUTPUT dir of the crate in question. Or target dir since the OUTPUT dir can change?

We shouldn't use OUTPUT dir the whole idea is to cache the downlloaded file in known location that will be still cached even if we rebuild the whole project / delete target folder and rebuild

[thewh1teagle]

I'd expect at least some level of documentation what all that black magic does. Whats more is that I can guarantee that there are few that even dare to touch this code and I don't want to maintain this code.

It just returns the cache directory on different platforms

[juhaku]

Rather than using path/to/internal/mod.rs use path/to/intenral.rs This is a better syntax and is the recommended syntax over the mod.rs files. Eventually the code base ends up having a billion mod.rs files and that is not really compelling.

See more here:
https://doc.rust-lang.org/book/ch07-02-defining-modules-to-control-scope-and-privacy.html#modules-cheat-sheet
https://doc.rust-lang.org/stable/book/ch07-05-separating-modules-into-different-files.html#alternate-file-paths
https://doc.rust-lang.org/edition-guide/rust-2018/path-changes.html#no-more-modrs

The mod.rs syntax is old relic pre 2018 Edition time (before Rust 1.31) just to make the Rust compiler support the modules.

[thewh1teagle]

Nice! didn't knew we can do the same thing without using mod.rs files. thanks

[juhaku]

But what happens if the user changes the url? I guess the validation will then just fail?

[juhaku]

Ah, it is only used as a suffix, well this is not very good to be hard coded because users can change the SWAGGER_UI_DOWNLOAD_URL which effectively is changing the version that changes the hash as well.

[thewh1teagle]

Ah, it is only used as a suffix, well this is not very good to be hard coded because users can change the SWAGGER_UI_DOWNLOAD_URL which effectively is changing the version that changes the hash as well.

I think we should avoid use cache if user supplied the URL

[thewh1teagle]

Added documentation and simplified the implementation. If this looks good, I'll squash the commits.