Re: [Groff] [groff/patch] transparent gzip

[Ralph Corderoy]

Hi Mark,

> > So is it worth the extra code which the reader has to parse?  (I know
> > what stdlib routines do without having to look up their definitions.)
> > And how about .bz2, .lzo, etc.  Isn't it the Unix way to keep this kind
> > of thing separate?
> 
> There is yet another engineering principle of trying to limit the
> number of technologies you use within a system (using 5 languages to
> program one system for example is ridiculous). Groff is already using
> C. It already detects the compiler. It already has autoconf support.
> Making groff be able to decompress on the fly is easy (detect libz at
> autoconf time and link). This does not add any technology that groff
> was not previously using. It doesn't make groff more complex

You do not address the point I explicitly made about having another
layer of routines to drill-down into when reading the source as the
stdlib ones are no longer used.  I think that does make it more complex.

> except a small piece of code inside it.

Nor the point about other compression formats.  You argument stands just
as well for bzip2, lzop, and the other compressors that follow, but not
exactly, gzip/zlib in packaging and style.  Should we add all these into
groff?  What about wc?  grep?

I agree that we don't *have* to stick to process boundaries to implement
new functionality, but transparent decompression belongs in a library
outside of groff, for all to use.

No doubt someone's already written one and someone else has done patches
for glibc.

That must be $0.05 by now  :-)


Ralph.