home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 128 < prev    next >
Internet Message Format  |  1990-12-05  |  3KB
  1. From std-unix-request@uunet.uu.net  Tue Sep 25 10:37:08 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA00719; Tue, 25 Sep 90 10:37:08 -0400
  4. Posted-Date: 24 Sep 90 21:30:35 GMT
  5. Received: by cs.utexas.edu (5.64/1.76) 
  6. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  7. Newsgroups: comp.std.unix
  8. Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
  9. Message-Id: <540@usenix.ORG>
  10. References: <523@usenix.ORG> <524@usenix.ORG> <528@usenix.ORG>
  11. Sender: jsq@usenix.ORG
  12. Organization: IR
  13. X-Submissions: std-unix@uunet.uu.net
  14. Date: 24 Sep 90 21:30:35 GMT
  15. Reply-To: std-unix@uunet.uu.net
  16. To: std-unix@uunet.uu.net
  17.  
  18. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  19.  
  20. In article <528@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  21. > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  22. > >The beauty and power of UNIX is the abstraction of files---
  23. > >not filesystems.
  24. > Both the filesystem and the file descriptor are powerful abstractions.
  25.  
  26. On the contrary: Given file descriptors, the filesystem is an almost
  27. useless abstraction.
  28.  
  29. Programs fall into two main classes. Some (such as diff) take a small,
  30. fixed number of filename arguments and treat each one specially. They
  31. become both simpler and more flexible if they instead use file
  32. descriptors. I'll propose multitee as an example of this.
  33.  
  34. Others (such as sed or compress) take many filenames and perform some
  35. action on each file in turn. They also become both simpler and more
  36. flexible if they instead take input and output from a couple of file
  37. descriptors, perhaps with a simple protocol for indicating file
  38. boundaries. I'll propose the new version of filterfile as a
  39. demonstration of how this can simplify application development.
  40.  
  41. In both cases, the application need know absolutely nothing about the
  42. filesystem. A few utilities deal with filenames---shell redirection and
  43. cat. A few utilities do the same for network connections---authtcp and
  44. attachport. A few utilities do the same for pipes---the shell's piping.
  45. But beyond these two or three programs per I/O object, the filesystem
  46. contributes *nothing* to the vast majority of applications.
  47.  
  48. There is one notable exception. Some programs depend on reliable,
  49. static, local or virtually local storage, usually for what amounts to
  50. interprocess communication. (login needs /etc/passwd. cron reads crontab.
  51. And so on.) This is exactly what filesystems were designed for, and a
  52. program that wants reliable, static, local storage is perfectly within
  53. its rights to demand the sensible abstraction we call a filesystem.
  54.  
  55. Most applications that use input and output, though, don't care that
  56. it's reliable or static or local. For them, the filesystem is pointless.
  57. Many of us are convinced that open() and rename() and unlink() and so on
  58. are an extremely poor match for unreliable or dynamic or remote I/O. We
  59. also see the sheer uselessness of forcing all I/O into the filesystem.
  60. You must convince us that open() makes sense for everything that might
  61. be a file descriptor, and that it provides a real benefit for future
  62. applications, before you destroy what we see as the beauty and power of
  63. UNIX.
  64.  
  65. ---Dan
  66.  
  67. Volume-Number: Volume 21, Number 128
  68.  
  69.