Closed mperham closed 8 years ago
@mperham: I was thinking about BakedFile to behave "same" as classic File. Compression is just medium to minimize size of binary and memory footprint when loading whole thing.
With this premise I think there should be 3 "readers" for each file, which are usefull across all usecases
1) encoded
: returns base64 encoded.
2) read
: return raw content same as File.read
3) to_slice
: returns Slice for IO
When you need compressed file (i.e. for web server, which is just one case of many) then there can be API like I tried to design there https://github.com/mperham/sidekiq.cr/pull/29#issuecomment-230461200
Edit: I am trying to make some universal swiss army knife as usually. As I read your comments one more time, it make me more sense :)
Sounds good to me. My API tries to minimize uncompression but you are welcome to tweak as necessary.
I've updated the APIs based on your feedback. WDYT?
This PR gzip compresses all files before storing them into the binary. It also adds APIs so the file contents can be accessed both compressed or uncompressed, allowing for efficient serving of assets to browsers which accept gzip (which is 99% of them).
In my view, the 80% use case of this shard is for storing compressible web assets (e.g. JS, CSS) where compression gives a huge win in size. The test suite contains a PNG that I crushed with
pngcrush
and it still compressed another 10% with gzip. In other words, I don't believe it's worth it to support disabling compression for certain filetypes.Fixes #2