Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!cmcl2!nrl-cmf!ames!lll-lcc!pyramid!vsi1!lmb From: lmb@vsi1.UUCP (Larry Blair) Newsgroups: comp.sources.d Subject: Re: Poll on shar formats Message-ID: <640@vsi1.UUCP> Date: 5 Jun 88 05:45:42 GMT References: <868@fig.bbn.com> <1494@microsoft.UUCP> <4838@teddy.UUCP> <887@fig.bbn.com> <2201@epimass.EPI.COM> Reply-To: lmb@vsi1.UUCP (Larry Blair) Organization: VICOM Systems Inc., San Jose, CA Lines: 21 In article <2201@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >When used with compress, the cost of the X is essentially zero, >because the sequence "\nX" in the shar file has the same frequency >that "\n" would if you used cat. By making the statistical frequency >of patterns in the file more erratic, you might actually INCREASE the >size of compressed shar files with your scheme. Joe has brought out a point that is often overlook in all discussions of how to reduce net traffic. Since it can be assumed that nearly all net traffic is compressed, any changes to reduce the quantity of data must be aimed at reducing the total *compressed* data. I'm not forgetting that Rich's proposed shar format would save disk space. It's just that the amount saved would be unlikely to completely fill a filesystem that wouldn't otherwise run out of room. -- * * O Larry Blair * * O VICOM Systems Inc. sun!pyramid----\ * * O 2520 Junction Ave. uunet!ubvax----->!vsi1!lmb * * O San Jose, CA 95134 ucbvax!tolerant/ * * O +1-408-432-8660