[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Mark Veltzer
Subject: Re: [Groff] [groff/patch] transparent gzip
Date: Sat, 24 Aug 2002 23:15:20 +0300

Hash: SHA1

On Saturday 24 August 2002 22:31, you wrote:
> 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?

My opinions on the matter:
The UNIX way is not different from the basic of most fundamental engineering 
rules of thumb: when designing a complex system divide it to components along 
the lines of the minimal and most well defined interface and make each 
component do it's thing and only it's thing in the most flexible but best 
possible way. Someone, in UNIX computing, that equation was:


which is not neccessarily the right interpretation. In languages such as C 
and C++ components are either shared libraries or objects.

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 except a small piece of code inside it.

I therefore support gz inside groff (optional ofcourse). 

Just my opinion.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]