🚀 go-pugleaf

In article <C1I4Mu.Hn7@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>The new GNU "gzip" program is supposed to do considerably better.  (It may
>also be faster; "freeze" is really slow,...

It is. A sample over 130K news batches from comp.windows.x showed that
freeze and compress really lose.

The batches are compressed to about 58K, frozen to 40K, and "gzip"-ped
to 34K. While the gain is not as much as between compress and freeze,
it is still appreciable.

The CPU needed is somewhat between compress and freeze. It would be
really hard to beat the simplicity of compress. :-)

>... I'm debating how to handle this in C News; I
>really, really do not want to have to maintain an ever-growing list of
>magic numbers inside newsspool.

Simple. Revert to the old B-news scheme of things: If it begins with a
#! something, then pipe the remainder thru the filter
/usr/lib/newsbin/unbatch/something to produce the newsbatch before
calling relaynews. Then users can add without worrying unbatching methods,
just like they can add batching methods now.

(To speed up the thing, newsspool should store batches as .t files if they
 are text or #! rnews batches, and .x - for example - if they begin with
 an unbatching method header)
-- 
	Vincent Archer			Email:	archer@frmug.fr.mugnet.org
Reality is for those who can't face Science Fiction.