Re: compression/conversion

[rubywand@aol.com]

In article <32E44389.1DA0@pacbell.net>, Scott <dack@pacbell.net> writes:

>does anyone else find it ironic that you need binscii to de-code
>shrinkit, and shrinkit to uncompress binscii? specifically:
>http://www.cfn.cs.dal.ca:80/Services/PDA/AppleGSCompression.html
>-

     It is sort of ironic.

     As explained in FAQ 2.4 and the BINSCII docs, the main purpose of
binscii-encoding is to protect files, usually .SHK file archives, from
being messed around when transmitted via email or to sites which may not
handle plain binary files correctly.

     The up-side is that the technique usually works. The down-side is
that binscii-encoding (1) increases file size,  (2) necessitates using a
binscii decoder on the file when it is downloaded, and (3) makes it harder
to verify correct uploads using simple original vs. uploaded file-size
comparisons. 

     Today, most .SHK uploads go to ftp sites which, typically, have no
problem  handling binary files. Binscii-encoding is not necessary. Users
just need to remember to set "binary" mode when uploading an .SHK file and
"ascii" mode when uploading text files they wish to be viewable on-line.

     Another, generally, unnecessary practice is the use of Binary II
"wrappers". ShrinkIt preserves all file type information in .SHK file
archives and the .SHK file itself does not need to have its file type
preserved.

     Unlike binscii, Binary II does not change the entire file and the
size increase is small. Spectrum, ProTerm 3.1, and other telecom wares
have no problem checking incoming files for Binary II and doing the
unwrapping automatically.

     Binary II is not a great bother. On the other hand, it does not,
usually, do anything useful; and, since file size of an .SHK file which is
"Binary II Up" loaded to an ftp site is changed, it is more difficult to
get a quick size check.

     In short, there is some irony in the continued automatic application
of binscii, uuencode, Binary II, ... . The irony is that, more and more,
these schemes which aim to protect data transfers are unnecessary and,
often,  just end up confusing users and getting in the way of successful
transmission.


Rubywand