Xref: utzoo alt.sources.d:1243 comp.sources.d:6215 Path: utzoo!utgpu!cs.utexas.edu!swrinde!mips!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: alt.sources.d,comp.sources.d Subject: Re: Read this if you're having trouble unpacking Tcl Message-ID: <1990Dec28.075123.6114@zorch.SF-Bay.ORG> Date: 28 Dec 90 07:51:23 GMT References: <88817429@bfmny0.BFM.COM> <1990Dec27.071632.7272@zorch.SF-Bay.ORG> <97261639@bfmny0.BFM.COM> Distribution: alt Organization: SF-Bay Public-Access Unix Lines: 65 Many of your points are good ones, however, I cannot let you so lightly dismiss a couple of them. Uuencoded files have nice, regular, short lines, free of control characters, that transit gateways and news software well. I don't want to tell someone with a 132 character wide screen who's trying to decide whether it's worth the pain and torment to publish their code for the benefit of the net that s/he can only write code in the left 3/5ths or so of the screen because the USENet news software is braindead. Allowing programmers to transport the code in a manner that will survive the real world net without a prior hand reformat is a must. Moreover, uuencoded files of the more modern kind do a line by line validity check, much more robust than shar's character count. I've unpacked many damaged source files from the net that had correct character counts, but damaged bytes in the files. This leads to subtle and time consuming debugging, since you can easily get errors that don't cause compiler errors by trashing just a byte or two, especially if you get lucky and hit an operator and convert it to a diffent operator. The transit from ASCII to EBCDIC and back irreversably destroys some of the bracket characters, I forget which ones. This is not a trivial problem to fix in the source code. Sending the code with a uuencode varient that avoids characters that don't exist in both character sets avoids that damage. The savings of 600Kbytes of spool storage space for tcl as sent means about 300 news articles can escape the expire cleaver until that distribution expires. On a small system like the home hobbiest system on which I have an account, that is a great benefit. With most traffic volume passing through the Internet, just now communications is not the overwhelming, all other consideration dismissing bottleneck to USENet that it was four years ago; disk space, however, is in even shorter supply; a posting in another newsgroup mentions that the net news volume doubles every eighteen months, which is faster than spinning storage grows cheaper by half. Attention to efficient storage methods in news spools is thus a valid and ongoing issue (in fact, I wish news were stored compressed and accessed with a pipe through zcat or by a "copy and uncompress to /temp, read, and discard the copy" strategy; I'd willingly pay the wait time to have a longer expire time), so receiving _and_ _storing_ until its expiration time a more space efficient format such as the compressed, uuencoded tcl distribution helps every site's expire times and helps avoid news spool overflow. Your expressed concern is that the files do not meet the "USENet way" of distributing source code. This is probably not a surprise to you, but we're not just USENet any more; we have subscribers on BITNET, EUnet, FidoNet, and many other networks, even CompuServe. Getting source material intact through all the possible protocals is a non-trivial challenge, but the regularity and limited character set of uuencoded data sure helps. Paying a penalty (around 10%) in communication time is at least arguably worth it to be able to tie so much bigger a world together. Like you, I prefer to see nice neat open ASCII shars posted, but I grow more and more willing to tolerate ever stranger formats as my own coping skills for them increase, especially when many of the options offered, such as damaged receipt, or news spool space crunches, are worse. Kent, the man from xanth.