Xref: utzoo comp.binaries.ibm.pc.d:214 comp.sys.ibm.pc:15473
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!oberon!sdcrdcf!burdvax!udel!princeton!phoenix!rjchen
From: rjchen@phoenix.Princeton.EDU (Raymond Juimong Chen)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: File Transmission Standards
Message-ID: <2865@phoenix.Princeton.EDU>
Date: 12 May 88 02:35:33 GMT
Organization: Princeton University, NJ
Lines: 47

I sort of got into this discussion after it had gotten started,
so please pardon me if this has been brought up before:

Is there a compelling argument against having each uuencoded file
be an independent .ARC/.ZOO file?  This way, when multipart programs
come through and a part gets munged, we can uudecode what we have
so far and test it and evaluate it (or at least the part that
got through) immediately instead of waiting around for mail/reposting,
then gluing the parts together (in order!), then uudecoding, then
un-arcing and evaluating.

: If this has been hashed/rehashed, pretend the line eater got the :
: rest of the file :

This also solves the "what if the parts come in in the wrong order"
and the "I hate cutting and gluing" problem:  since each part is
a separate archive, it doesn't matter what order you get them.
Since each part is an independent archive, you don't have to do any
cutting and pasting at all.  (uudecode ignores headers and trailers.
Then again, what happened to atob?)

One problem would occur if a single file, when arc'd and uuencoded,
is still too large for transmission as a single file.  This is a case in 
which cutting is probably the only viable solution.

A possible counter-argument is that it would create lots of archives
with similar names (like dsz1 dsz2 dsz3... dsz9) which would then have
to be re-combined by the receiver.  Or, if you can't de-archive on
your host machine, it means that the number of files you have to
transfer is ten instead of one.  To the first, I say "Gosh, that's
too bad."  There do exist programs which can combine archives without
extracting/recompressing each file.  (I believe that SEA arc comes
with one [MARC I believe it's called], and I presume that ZOO has
a similar capability.)  To the second, I argue that it actually makes
life easier:  The total time for transfer is marginally larger, but
[1] it placates people who say "Gosh, how am I going to fit a 700K
archive onto my 360K floppy?", [2] if something goes wrong
with your connection, you only lose the last file you were transferring
instead of losing the entire file.

Such is my $0.02 worth.  (And when is c.b.i.p going to get moderated?)

-- 
Raymond Chen	UUCP: ...allegra!princeton!{phoenix|pucc}!rjchen
		BITNET: rjchen@phoenix.UUCP, rjchen@pucc
		ARPA: rjchen@phoenix.PRINCETON.EDU
"Say something, please!  ('Yes' would be best.)" - The Doctor