The problem with huge installers using "whole compression" mode is the slow initialization time of the installer. I'm still using zlib compression for my installers because I hate to wait for installers (worst is the InstallShield + MSI combination).
The benefit of lzma + whole compression is the reduced installer size.
Zlib compression on the other side is the fastest, especially since every file gets compressed individually.
Now I had the idea of compression blocks, each consisting of one or more files.
For this I would introduce some new commands:
Blocks can be nested in the sources (for use in macros with plugins for example). Inside a block, every instruction which causes a file to be added to the installer, will be added to the specified compression block.
If blocks with the same name already exists, any additional files will be appended.
If no block is open, a default block will be used.
So I could for example call BeginCompressionBlock at each section (and EndCompressionBlock at the end).
That way only the files for the sections which will be installed will be extracted. The remaining files won't be touched, as opposed to the current solid compression where those files still get extracted but discarded.
Hence it will also be possible to use seperate compression blocks for the install code/data and the plugins, thus dramaticaly reducing initialization time while still keeping a good compression ratio similar to old solid mode.
This would be a very useful feature for complex projects. Best example I can think of would be projects like XAMPP or other meta-projects.
Would it be very hard to implement this?