Forum unknown
· Telecommunications
#AmigaBinary
3 messages in this thread
Yet another AB thot:
The inclusion of LAR & ARC in the compression bytes seems too ambitious to me.
Since these are multi-file formats in themselves, I feel they should be left to
the user to unpack. Personally, I would like to get my hands on the Crunch
algorithm used in ARC, and apply it to the file as it is up/downloaded. Since
Crunch is a one-pass compression scheme, and it usually results in a better
compression than even Squeeze (which is a two-pass algorithm), it would make a
great default upload compression. As for the compression byte definition in
AB, I would suggest: 0==uncompressed, 1==squeezed, 2==Crunched, & 3==packed
for now. The receiving-file display should at least tell the user what packing
method was used, even if it is not going to unpack it. For example:
Receiving:
Name: Size Compression
————- —- ———–
File1 4096 (squeezed)
dir1 (dir)
File2 9873 Uncrunching…
File3 8734 (Unknown 6)
File4 58
The user is being told that File1 is squeezed, but we didn't unsqueeze it, we
don't even know what File3 (compression # 6) is, but that File2 was crunched,
but was uncrunched as it was downloaded. An option to save the previous
receive-list to disk would give the user something to refer to when it comes
time to manually decompress things.
–Wayne
* Reply:
10544
Uh-uh. We are not defining any NEW squeezing/packing/crunching/etc algorithms
here, even ones that are incorporated into ARC. The idea is that with the
current setup, a terminal program can opt to deal with squeezed/etc formats by
calling up one of the standard programs. That is, it doesn't have to deal with
it directly. Sure, the more powerful programs will eventually include direct
provisions for them, but that will be later. And as I said, the overhead of
ARCing a single file rather than a whole bunch is pretty minimal. I see 3
levels of squeeze support: lowest level is to simply pull out the files and
report to the user that they need to be operated on; next level is to call up
the PD programs USQ, LAR, ARC, and have them do the work; highest level is to
do it internally to the terminal program.
There is a problem that I didn't think of, though: what if it is desirable to
squeeze/etc the .info file or the comments? It probably wouldn't do much good
on comments, but how big can a .info grow? There might be good reason to
compress them. One way to deal with that would be to ARC the file and
file.info together into a single file, leave the .info field empty, and set the
ARC flag. Not too pretty, though. Anyway, I want the compression formats to
be real easy to deal with, by calling up the standalone compression programs.
No new formats. – Bela
* RR 10490
Uh-uh. We are not defining any NEW squeezing/packing/crunching/etc algorithms
here, even ones that are incorporated into ARC. The idea is that with the
current setup, a terminal program can opt to deal with squeezed/etc formats by
calling up one of the standard programs. That is, it doesn't have to deal with
it directly. Sure, the more powerful programs will eventually include direct
provisions for them, but that will be later. And as I said, the overhead of
ARCing a single file rather than a whole bunch is pretty minimal. I see 3
levels of squeeze support: lowest level is to simply pull out the files and
report to the user that they need to be operated on; next level is to call up
the PD programs USQ, LAR, ARC, and have them do the work; highest level is to
do it internally to the terminal program.
There is a problem that I didn't think of, though: what if it is desirable to
squeeze/etc the .info file or the comments? It probably wouldn't do much good
on comments, but how big can a .info grow? There might be good reason to
compress them. One way to deal with that would be to ARC the file and
file.info together into a single file, leave the .info field empty, and set the
ARC flag. Not too pretty, though. Anyway, I want the compression formats to
be real easy to deal with, by calling up the standalone compression programs.
No new formats. – Bela
* RR 10490