Opened on 06/13/2016 at 12:25:18 PM
Closed on 10/11/2016 at 03:05:20 PM
#4149 closed change (rejected)
Compression of Edge extensions in buildtools
Reported by: | kvas | Assignee: | |
---|---|---|---|
Priority: | Unknown | Milestone: | |
Module: | Automation | Keywords: | |
Cc: | Blocked By: | #4028 | |
Blocking: | Platform: | Unknown / Cross platform | |
Ready: | no | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description (last modified by kvas)
Background
#4028 adds support for Edge extension packaging. However, that implementation doesn't support compression of the resulting Appx file.
The reason for that is that Appx file includes package block map that must contain the sizes of each 64k block of the file after it's been compressed. It's not possible to obtain this information for files that are bigger than 64k when they are compressed and added to the archive using zipfile API. We've chosen to work around this by not using compression. In this case the compressed size of each block is the same as its uncompressed size and the block map can be produced without looking at the resulting archive.
The workaround leads to large packages being produced, so it would be more desirable to use compression. This can be achieved by implementing a version of ZipFile.writestr that would ensure that 64k chunks end on byte boundaries in the resulting compressed stream return the sizes of the chunks after compression.
What to change
- Subclass zipfile.ZipFile from python standard library, copy ZipFile.writestr to a new method and modify it to compress files by 64k chunks performing compress object flushes between them and calculating the compressed sizes. Return the list of compressed sizes.
- Modify packagerEdge.Files.zip to use the new class and call the new method. Use the returned data to produce correct block map and add it to the archive as the last item.
Note: there are differences between ZipFile implementations in Python 2 and 3. It seems possible to implement a universal method that would work with both and this would be preferable.
Windows Store repackages extensions with compression so it doesn't really matter if we compress them or not.