You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We'll be using zip as our starting general archive format. If we need to aggregate files into a single blob, zip is such a widely deployed format that there isn't a reason to invent one. We'll already be using it to bundle compressed files with executables as a polyglot file a la redbean for our compiler. We'll probably use it to export/download parts of the Wanix filesystem, as well as include certain filesets in the bundled bootloader.
And leaning into our filesystem abstraction, it will likely be helpful to have a zipfs. One first usecase is to allow user zip files on the filesystem to be automatically explored (similar to Windows). In the case of our compiler build, as it is also a zipfile containing the precompiled standard library, zipfs could be used to just mount the file instead of extracting and writing files out to be used, then deleting them. Not a material benefit, but seems cleaner.
A simply read-only zipfs using the Go standard library's zip package is already implemented in afero and would be trivial to port to our FS abstraction.
The text was updated successfully, but these errors were encountered:
We'll be using zip as our starting general archive format. If we need to aggregate files into a single blob, zip is such a widely deployed format that there isn't a reason to invent one. We'll already be using it to bundle compressed files with executables as a polyglot file a la redbean for our compiler. We'll probably use it to export/download parts of the Wanix filesystem, as well as include certain filesets in the bundled bootloader.
And leaning into our filesystem abstraction, it will likely be helpful to have a zipfs. One first usecase is to allow user zip files on the filesystem to be automatically explored (similar to Windows). In the case of our compiler
build
, as it is also a zipfile containing the precompiled standard library, zipfs could be used to just mount the file instead of extracting and writing files out to be used, then deleting them. Not a material benefit, but seems cleaner.A simply read-only zipfs using the Go standard library's zip package is already implemented in afero and would be trivial to port to our FS abstraction.
The text was updated successfully, but these errors were encountered: