Comments on: Extending COMPRESS with Zip
As pointed out in this REBOL zip archiver and unarchiver script, it is possible to extend REBOL with the standard zip, even as a script.
Of course, it's also been pointed out that this feature should be built-in, since most of the algorithm is already part of REBOL.
We can keep the REBOL compress function as it is for compatibility, but add one or more refinements to do zip.
Here's the plan: I will add it to REBOL 3.0, if I can get some volunteers to work with me to define the necessary refinements, C code, and tests. After that tests out, I can back-port it to 2.7 with little effort.
I'm not sure if I need zip so much. What I would like to see is some update of decompress function. I guess it's using some older zlib version as I have problems to decompress some zlib data which I can decompress without problem using zlib.dll version 1.2.3 (most of the zlib compressed string is possible to decompress using Rebol decompress function)|
Adding refinements to COMPRESS makes sense for simple zip data/file creation, but how will it work for adding or deleting files in an existing archive, getting TOC/header info, etc.? I guess that's the "define the necessary" part, but compress and decompress are words with a single, clear purpose. Unless the /zip refinement leads to a dialected interface or something.
Oldes, I see this as an important interop feature. Many things use the zip format today, not to mention being able to create zip files for our own uses, that I think there's a lot of value in supporting it. Besides native JPG saving, this is one of the few things I need to use external tools for.
How hard would it be to implement as a scheme? Or would it be better to do it in DE/COMPRESS and then create the scheme over that? Or maybe a dialected ZIP function?|
Good point, Gregg. How can we compress large files, if not implemented as a scheme?|
Hmm... 7zip is LGPL - *could* be used.|
Built in zip would be one less step to perform externally. We send out zipped files to our clients nearly everyday. Those files have been processed by REBOL. On Win32, an external program has to be installed to zip files. (That is installed on our UNIX platform anyway). However it's implemented, I think it's a great extension to compress.
I'd like to see a more generic approach to compression support, relying on schemes, like encryption does. Something like a ZIP:// port (mezz level) built upon a COMPRESS:// sub-port (native level). The COMPRESS:// scheme would give us access to all the compression parameters (like the compression level for 'zlib). Then we would just need some of the native functions used by Vincent from the PNG loader, being exposed to higher level, to be able to implement a complete and clean ZIP:// scheme at mezzanine level.
In this approach, DE/COMPRESS functions could be redefined like this :
compress: func [
port: make port! [
algorithm: any [name 'zlib] ; default: 'zlib
strength: any [level 6] ; default: 6 for 'zlib
insert port data
result: copy port
decompress: func [
port: make port! [
scheme: 'compress ; here 'algorithm and other parameters are
direction: 'expand ; read from the header part of data.
insert port data
result: copy port
I like the ZIP and UNZIP functions provided by Vincent's library. They could be easily implemented upon a ZIP:// scheme.
Just my 2 cents...
I like DocKimbel's comment and have been thinking about it the same....making something like a COMPRESS scheme would be great.|
Add an "I agree" to DocKimbel and Cyphre's comments. A port scheme and a nice dialect frontend would be nice.
I've gotten so used to using Vincent's rebzip, that it feels builtin already.
Bohdan's align.r and rebzip.r are two defacto includes in the scripts I use.
This will be a worthwhile effort IMHO.
As far as helping out, I don't know how much value I'll add on the C side, but I'm happy to help with the interface design.|
I say start small and add features later.
Main purpose of zip is to put many files into one, for browser-uploads, attachements etc. its not the compression-part which is most important. Its the "bag of files".
For that a simple zip/unzip would do, as long as data fits in memory. Maybe zip/unzip a block with [file data file2 data2].
I would like a real scheme too, but i think that is lots more work. And such extensions can be later added in a compatible way. And a simple zip/unzip will be build on top of it anyway, for the 95% where i want to send this files there.
About help, i would try, but i lack routine on the toolchain-level. Makefiles and that..
I would like a zip:// scheme that could be browsed like a directory and files, using list-dir and such. I would also like to write and read files in a zip file like it was a directory or an FTP site. Compression details could be specified with /custom.|
I totally agree with Brian - that is the way to go. The original idea of mine to add .zip was always to have it available like scheme. I would even like to have it transparent like:
file: read %/C/REBOL/View/my-zip.zip/my-file.r
Not sure it would be possible, but at least scheme/port aproach sounds good to me. I would hate to see just yet another func added to rebol, like do-browser, because it was said we use ports as a means of external environment abstractions. Let's stick with it on low-level, or the concept is not clean ...
There are several related LZ compression functions, such as Zip, Gzip, Bzip2, and 7zip, so however this is implemented, it should be generic enough to be extendable for those related formats.|
which has a BSD-like license.
sasa adad dsdsds fsfsfs|
Post a Comment:
You can post a comment here. Keep it on-topic.