Comments on: Extending COMPRESS with Zip
REBOL Technologies

Comments on: Extending COMPRESS with Zip

Carl Sassenrath, CTO
REBOL Technologies
4-Apr-2007 20:51 GMT

Article #0330
Main page || Index || Prior Article [0329] || Next Article [0331] || 16 Comments || Send feedback

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.



4-Apr-2007 14:27:36
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)
Gregg Irwin
4-Apr-2007 16:41:26
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.

Gregg Irwin
4-Apr-2007 16:50:46
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?
Anton Rolls
4-Apr-2007 20:18:43
Good point, Gregg. How can we compress large files, if not implemented as a scheme?
Anton Rolls
4-Apr-2007 20:27:02
Hmm... 7zip is LGPL - *could* be used.
Dave Cope
5-Apr-2007 1:32:53
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.


5-Apr-2007 4:36:17
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 [
    data [any-string!]
        port result
    port: make port! [
        scheme: 'compress
        algorithm: any [name 'zlib]  ; default: 'zlib
        direction: 'reduce
        strength: any [level 6]      ; default: 6 for 'zlib
    insert port data
    update port
    result: copy port
    close port
decompress: func [
    data [binary!]
        port result
    port: make port! [
        scheme: 'compress   ; here 'algorithm and other parameters are 
        direction: 'expand  ; read from the header part of data.
    insert port data
    update port
    result: copy port
    close 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...

5-Apr-2007 4:55:03
I like DocKimbel's comment and have been thinking about it the same....making something like a COMPRESS scheme would be great.
Brian Tiffin
5-Apr-2007 5:49:21
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.

Gregg Irwin
5-Apr-2007 11:32:44
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.
5-Apr-2007 11:44:40
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..

Brian Hawley
5-Apr-2007 12:05:20
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.
5-Apr-2007 14:51:56
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/

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 ...

5-Apr-2007 17:17:33
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.
Anton Rolls
9-Apr-2007 21:26:56
which has a BSD-like license.
9-Feb-2009 2:54:15
sasa adad dsdsds fsfsfs

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 1-Jun-2023   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code