Xref: utzoo comp.binaries.ibm.pc.d:343 comp.sys.ibm.pc:16056
Path: utzoo!attcan!uunet!husc6!rutgers!cmcl2!phri!dasys1!tneff
From: tneff@dasys1.UUCP (Tom Neff)
Newsgroups: comp.binaries.ibm.pc.d,comp.sys.ibm.pc
Subject: Re: Source code newsgroup for MS-DOS
Summary: Rahul can help us out here
Message-ID: <4732@dasys1.UUCP>
Date: 31 May 88 16:34:42 GMT
References: <1555@bu-tyng.bu.edu> <3186@bsu-cs.UUCP> <11803@ut-sally.UUCP> <7978@brl-smoke.ARPA> <4827@teddy.UUCP> <2143@rpp386.UUCP> <4831@teddy.UUCP>
Reply-To: tneff@dasys1.UUCP (Tom Neff)
Organization: Independent Users Guild
Lines: 54

John Nelson makes some interesting points about shar vs. ARC or whatever
for posting sources and binaries to Usenet.  Let me make a couple of points
of my own.

 * Compressing sources into an ARC or ZOO bundle, then uuencoding and
posting, seems to me to be a bad idea.  The arguments over how much you
save in filesize don't take into account the amount of bandwidth required
to actually do the send, or the amount of CPU required to pre- and post-
process everything.  I can already tell when this mini is into its daily
newsfeed decompress - things slow down.  Adding to this unnecessarily
should be avoided.  Also, I think it's important to be able to browse
the contents of a source posting in easily readable ASCII form, before
deciding whether to do anything with it.  I get upset seeing someone post
a source bundle described as "neat C routines to do this-n-that" only
to see a vast, dismal wall of UUENCODE hieroglyphics staring at me. I
have to grab it, cut and paste, decode, de-ARC or whatever, and only then
can I see it's a bunch of freshman functions or the greatest thing since
sliced bread.

 * However, the existing shar mechanism is somewhat deficient by comparison
with what ZOO or ARC offers.  Specifically, you get much better checksumming
("99% of transmission errors" is probably inaccurate, John, but even if
that's how good the character count trick was, 99% is considered a dismal
confidence rating for a software integrity algorithm), explicit control
on file dates/times, and (in the case of ZOO) subdirectory control where
that is important.
   On the other hand, ZOO in its present form does two things which cause
problems: It generates binary compressed files, running into my first
objection above; and it requires a decoder to make any sense of a ZOO file
at all.  The shell archive is self-contained (if you have a Unix shell or
workalike) and the contents are readable ASCII even before unpacking.
Bandwidth is well conserved too, since the 16-bit compress used with uucp
gives excellent numbers on ASCII text.

 * So we have a slight dilemma.  But I propose that Rahul give us a
technical solution!  He can add a new feature to ZOO that *generates
a shell archive* from the input files, instead of a compressed
binary .zoo bundle.  The input files would be assumed, of course, to be
ASCII text.  The special shell archive (call it a ZSA file) would 
be downward compatible with the existing shar format.  So if you don't
have the decoder, you can still extract files by running the thing.  But
it would also contain the additional control information ZOO retains,
including file dates, 32-bit checksums, subdirectory structure and so
on, in ASCII form in special comment lines.  That way, if you do have the
proper decoder, you can run it on the ZSA bundle to extract files with
exhaustive integrity checking, timestamp control, selectivity and whatever
else ZOO gives you.

   This seems to me to give us the best of both worlds.  What do you think?
Rahul?
-- 
Tom Neff			UUCP: ...!cmcl2!phri!dasys1!tneff
	"None of your toys	CIS: 76556,2536		MCI: TNEFF
	 will function..."	GEnie: TOMNEFF		BIX: are you kidding?