🚀 go-pugleaf

In article <1k77hr$a69@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes:
>> ... 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.
>
>Either use the m! XYZZY header as a handy excuse to call programm XYZZY
>(if present in a special directory, for security reasons) with the rest
>of the file on its stdin, or tell your feed to send gzipped data to
>zrnews, compressed data to crnews, frozen data to frnews.
>
>I'm more a friend of the second method; IMHO, it's the most direct way
>the sender (who already knows the packing method) can tell the receiver
>what to expect. No need for the receiver to go through contortions trying
>to find that out.

I agree with the general sentiments, but think I have a slightly better
slant on how to tackle it.  It is indeed a botch to have the sender not
tell the receiver what compression method is being used.  It's almost
as bad a botch to cram this information in-line, which makes processing
the resulting transmission rather awkward (for example, you can't use
the standard decompression programs unless you first strip off that
stupid header somehow).  It's best to indicate compression method by
some out-of-band channel like Matthias's second method.

There is a problem, however, with using different receiving programs
for different compression methods:  some old UUCP implementations have
the list of permissible remotely-run programs hardwired in, or otherwise
difficult to change, and often "rnews" is on the list but alternate
forms aren't.

Fortunately, there is a simple solution:  give the compression method as
an argument to rnews.  I can't see anything wrong with this, although I
need to sit down and sort out implementation details before I give it
the nod for sure.
-- 
"God willing... we shall return."       | Henry Spencer @ U of Toronto Zoology
       -Gene Cernan, the Moon, Dec 1972 |  henry@zoo.toronto.edu  utzoo!henry