Is The Script Compression Feature Necessary?

Development Optimization
1

R3-Alpha introduced the option that when you SAVE a script, you can ask that it be compressed.

It doesn't compress the header...just the body of the script. There were two options for how this body could be compressed after the header: either as a Base64 BINARY literal ("script compression"), or directly as gzip'd bits ("raw compression").

As an example:

>> data: save/compress blank [1 <two> "three"] 'script
== #{
    5245424F4C205B0A202020204F7074696F6E733A205B636F6D70726573735D0A
    5D0A3634237B483473494141414141414141436A4E5573436B707A3764545543
    724A4B45704E56654943414E425746325951414141417D
}

>> print as text! data
REBOL [
     Options: [compress]
]
64#{H4sIAAAAAAAACjNUsCkpz7dTUCrJKEpNVeICANBWF2YQAAAA}

>> [body header]: load data
== [1 <two> "three"
]

>> body
== [1 <two> "three"
]

>> header
== make object! [
    Title: "Untitled"
    File: ~null~
    Name: ~null~
    Type: 'script
    Version: ~null~
    Date: ~null~
    Author: ~null~
    Options: [compress]
    Description: ~null~
]

Rebol2 Didn't Have It, Red Doesn't Have It...

Arguments that it helps with transmitting over networks don't hold up much these days, because the HTTP protocol itself does compression.

Plus, keeping scripts in compressed form is an annoying form of opaqueness on a language that's supposed to be about simplicity.

I've kept it around just because there were tests for it, and it exercised compression code (including showcasing a really bad design method of trying to decompress garbage to see if it was the raw compressed form, causing a crazy memory allocation). But I'm not sure what the compelling use case for this feature is.

3 Likes