Re: IMPORTANT Message for all ACN Florida Mirror users

[CUTblakeney@home.com (Jeff Blakeney)]

On Sat, 26 Feb 2000 13:28:48 -0500 (EST), "Anon" <anonymous@cotse.com>
wrote:

>I understand your noting that these file types "should" be
>transferred as text files, but I for one, whenever I use
>ftp, always use binary mode. It was drummed into me
>years ago that a binary (i.e. "image") transfer would
>preserve all the file structure, which would include
>linefeed, CR's etc.  I've used this successfully with
>binscii and uuencoded files, and have had no problem
>recreating them on my end.  I for one would think that
>binary transfer for all files would be best.  (And if
>I'm wrong, I'm always open to knowing why so I can change
>what I'm doing.  :) )

Okay, there are a number of factors things involved here.

First, there is the MIME types on a server.  These types are used to
tell the server what mode to transfer the file in when it is in Auto
mode.  If you tell your client to download in binary mode then the
server should send to you in binary mode and leave the end of line
characters exactly as they are.  Without MIME types, it is anybodies
guess what mode it will try to send to you in.

Now, if you download a text file in binary mode, end of line
translations don't occur and that means that it is up to you or the
program you use to manipulate the file to deal with them.  In the case
of BINscii and UUencoded files on an Apple II, the decoding programs
usually don't care what the end of line character(s) is/are.

However, the same can't be said for all utilities on all systems and
some people might want to take a look at a BINscii file from another
machine if only to check that the lines are equal length to make sure
it downloaded okay and without the proper end of line character, the
file will not display correctly.

Also, by transferring in Text mode, the file you transfer can end up
being smaller.  Downloading a BINscii file that is on a server with
CR/LF end of line characters to a Mac or Apple II will which only uses
CR, you end up transfering one less character per line.  This means
that a file with 1000 lines of 64 characters followed by CR/LF (66,000
bytes) would end up being 1000 lines of 64 characters followed by CR
(65,000 bytes).  This translates into aproximately 1.5% savings in
both the size of file transfered and size of file you have to store.

Personally, it doesn't matter to me much whether bsc or bsq files are
transfered in Text or Binary mode as I never keep them.  I just decode
them back into their original files and delete the bsc or bsq file as
it is much larger than the binary version.  I also don't download a
bsq file if there is a bxy or shk version as the bxy or shk version
will be 1/8th the size of the bsq file.  :-)

I also don't personally see much reason for there being bsc or bsq
files on a web site unless they don't have the MIME types set up
correctly in which case some people will experience problems
downloading binary files so they can download the bsq version if they
are having a problem.  This is what I do with the files I make
available on the A2Pro web site on Delphi as I have no control over
Delphi's MIME types.  Having bsc or bsq files on an FTP site is pretty
much useless in my opinion as there should never be a problem
downloading binary versions of files.

But, what it all comes down to is, why not do things the way they are
supposed to be done?  :-)

+------------------------------------------------------------------------+
| Jeff Blakeney - Dean of the Apple II University in A2Pro on Delphi     |
|                    Delphi Apple II Forums Web Pages                    |
| A2: http://www.delphi.com/apple2   A2Pro: http://www.delphi.com/a2pro  |
+------------------------------------------------------------------------+