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?