Good morning, (Ted Harding) <ted.hard...@wlandres.net> wrote: [.] |As far as Unix/Linux are concerned, their beauty, simplicitly |and reliability, and above all their flexibility, depend on |the fact that different aspects of a program's functionality |for a specific purpose are delegated to components of the |program's software suite: In the words of the Founding Fathers, |each compenent does one thing, and does it well!
It must be said though that today it seems the complexity is enormous as is the program bloat. |But that is with reference to the specific purpose of the program, |which in the case of troff is the production of well-laid-out |pages -- a task which has many aspects. Oh more than is understood. |But decompressing files stored in compressed format on disk is |not one of these aspects. If it is desirable, then let it be So this is exactly what the patch is all about, snuggling in a specialist in between the undigested input data and the further refinement done by the typesetting system we use. |done by the operating system, independently of the program |(i.e. independently of troff). This must be possible, for a |suitable configuration of the operating system, if it is |desired and if suitable utility programs/routines are available |for the operating system. | |When a program needs a file, and transmits a call for it to |the operating system, and the operating system in turn finds |that it is a compressed file, then let the operating system |decompress it and pass it back undompressed to the program. Plan9 is great design. I really didn't know anything about it before Christos Zoulas of NetBSD pointed me to it because of my Unicode ambitions. Of course there is a performance bottleneck with all this data copying and the context switches. I'm the one who was happy once FreeBSD had zero-copy pipes. |Such tasks have nothing whatever to do with troff, and at many |points in the discussion is has appeared that making them part |of troff would introduce complications and potential diasters. For now most of the patch simplifies the code. This is desirable. The fourth and last patch which adds the decompressor pipe hook support, so if you want to, maybe; file extensions are a part of computer reality however, so i think automatic path adjustments are in this particular case ok, too, since we look into specific and configured search paths, and when i specify `.so file.1' and then troff also looks for `file.1.gz' and `file.1.bz2' shall there be no `file.1', then i think no terrible things should happen in practice. And with just one more day of work, or two, GNU troff(1) could also, optionally and easily, link against few of those dynamic libraries which have taken over the role of specialists in todays world, and use those instead of the external programs which provide the command line interface of exactly those libraries. I think it would be a fair deal to offer this functionality optionally for those who use a restricted troff merely for manual pages, for example. --steffen
