Xref: utzoo comp.mail.uucp:4346 comp.sources.d:5438 Path: utzoo!attcan!lsuc!eci386!clewis From: clewis@eci386.uucp (Chris Lewis) Newsgroups: comp.mail.uucp,comp.sources.d Subject: Re: WANTED: News compression information... Message-ID: <1990May31.200519.19379@eci386.uucp> Date: 31 May 90 20:05:19 GMT References: <1990May29.202056.26271@ox.com> <861@sppy00.UUCP> Reply-To: clewis@eci386.UUCP (Chris Lewis) Organization: Elegant Communications Inc. Lines: 73 In article <861@sppy00.UUCP> jmv@sppy00.UUCP (J. Vickroy +1 614 764 4343) writes: > In article <1990May29.202056.26271@ox.com> time@ox.com (Tim Endres) writes: > =>QUESTIONS: > =>Is "compress" the common news compression algorithm? In B-news and C-news "compress" is what is invoked. compress source comes with B-news, but apparently not C-news. I suspect TMN (aka news 3.0) uses compress too. > =>Do all news feeds compress at 16 bits or 12 bits? B-news by default uses whatever the compress source is compiled for. C-news by default uses 12 bits (because >12 bits isn't always possible on things like 286 Xenix or other small address space machines like pdp11's) regardless of how compress is compiled. 16 versus 12 bit usually only makes a difference of a few percent in size, but oodles in time (and memory space). B-news sites (particularly with scant CPU cycles and memory space) would be well advised to use -b12 anyways for outgoing batches (and possibly recompile for 12 bit provided that your feeders know about it). Build your Mac thingie with compress *compiled* for 12 bit compression, and include in the software notes that anybody feeding you has to set their compression to 12. Which means C-news feeders probably don't have to do anything, and B-news feeders have to stuff the "-b12" option into sendbatch's compress invocation (sendbatch can be parameterized for this I believe). Compress compiled for 12 bit compression has a data area of something like 32K compared to 400K+ when compiled for 16 bits. There's absolutely *no* problem with feeding 12 bit compressed data to a 16 bit compress program (it figures it out itself). (eg: a 12 bit feeding a 16 bit) The problem arises when a 16 bit compress program generates 16 bit output and tries to run it through a compress compiled for 12 bits. (eg: a 16 bit feeding a 12 bit) Just make sure that your compress source is at least version 4.0. > =>What are the implications of using compress in commercial sw? The source appears PD. Don't charge money for compress itself - the authors will get pissed.... Nor pretend you wrote it. A mention of the authors in your documentation would be nice... Given the source, you should be able to contact the original authors to make sure. > =>Are there any other, more miserly, compress programs available? Not that would be compatible with the majority of existing news sites. Please don't introduce another batch protocol! There appears about a dozen "supported" in B-news and C-news land, plus untold numbers in actual practise. (Though *all* of the compressed-batch protocols that are directly supported by the batchers use "compress" somewhere). The "standard" compressed batch format is a normal uncompressed news batch, run through compress, and occasionally (unmodified B-news) prepended with "#!cunbatch" or "#!rnews". C-news doesn't do the prepends, but will *accept* either prefix or none automatically. (which is what I suggest yours do too). > I've been told that the compression algorithm that sendbatch uses is > a "modified" L-Z. If this is true, then the PD compress should work. In true USENET tradition, the defacto standard is "compress". Which just so happens to be "an" implementation of L-Z. Without comparing output formats, there's no way of telling whether any other L-Z implementation would be compatible. -- Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list