Open larsbutler opened 10 years ago
I agree that if zapps are zerovm system images, then it probably doesn't make sense to gzip them.
Zerocloud supports .gz stuff, but the main idea of gz, I think, was to save traffic when uploading stuff
@pkit Yep, that's right. But if we run zapps locally, they can't be gzipped.
This is kind of my vision: to bridge the gap between "images" and "zapps". They're already so close. I would consider python.tar
to be a zapp, and I would like to have it in the ZPA. For example.
@rpedde
I agree that if zapps are zerovm system images, then it probably doesn't make sense to gzip them.
I would suggest that zerovm
should just decompress them on the fly. I'm sure we can put gzip
into ZRT and let it decompress the image too when it loads it.
Long term, it would good to have gzip support in ZeroVM. But for now, I think we can do without zipping. Assuming everyone actually agrees with treating system images and zapps as the same thing. Which not everyone does, apparently.
I don't like using the same file extension for files that are both compressed (on your system) and uncompressed (when deployed into Swift).
However, I just took a look at the python.tar
to get a real-world example. Compressing it with gzip
brings the size down from 70 MB to 19 MB. That is a much bigger saving than I had expected and this makes me want to push for adding gzip support to ZRT even more.
Maybe @pkit and @YaroslavLitvinov can comment on the feasibility of making zerovm and ZRT transparently decompress a system image when it is loaded? I haven't really worked with gzip in C, but it is my understanding that it is very easy to use.
In order to make zapps more easily consumable directly by ZeroVM, it would be useful to not gzip .zapp files. As far as I can tell, ZeroVM cannot directly mount a .tar.gz. However, you can mount a zapp directly (using
zvsh --zvm-image
, for example) if the file is just a tar.