home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0129.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.5 KB  |  52 lines
  1. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  2.  
  3. In article <528@usenix.ORG> chip@tct.uucp (Chip Salzenberg) writes:
  4. > According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
  5. > >The beauty and power of UNIX is the abstraction of files---
  6. > >not filesystems.
  7. > Both the filesystem and the file descriptor are powerful abstractions.
  8.  
  9. On the contrary: Given file descriptors, the filesystem is an almost
  10. useless abstraction.
  11.  
  12. Programs fall into two main classes. Some (such as diff) take a small,
  13. fixed number of filename arguments and treat each one specially. They
  14. become both simpler and more flexible if they instead use file
  15. descriptors. I'll propose multitee as an example of this.
  16.  
  17. Others (such as sed or compress) take many filenames and perform some
  18. action on each file in turn. They also become both simpler and more
  19. flexible if they instead take input and output from a couple of file
  20. descriptors, perhaps with a simple protocol for indicating file
  21. boundaries. I'll propose the new version of filterfile as a
  22. demonstration of how this can simplify application development.
  23.  
  24. In both cases, the application need know absolutely nothing about the
  25. filesystem. A few utilities deal with filenames---shell redirection and
  26. cat. A few utilities do the same for network connections---authtcp and
  27. attachport. A few utilities do the same for pipes---the shell's piping.
  28. But beyond these two or three programs per I/O object, the filesystem
  29. contributes *nothing* to the vast majority of applications.
  30.  
  31. There is one notable exception. Some programs depend on reliable,
  32. static, local or virtually local storage, usually for what amounts to
  33. interprocess communication. (login needs /etc/passwd. cron reads crontab.
  34. And so on.) This is exactly what filesystems were designed for, and a
  35. program that wants reliable, static, local storage is perfectly within
  36. its rights to demand the sensible abstraction we call a filesystem.
  37.  
  38. Most applications that use input and output, though, don't care that
  39. it's reliable or static or local. For them, the filesystem is pointless.
  40. Many of us are convinced that open() and rename() and unlink() and so on
  41. are an extremely poor match for unreliable or dynamic or remote I/O. We
  42. also see the sheer uselessness of forcing all I/O into the filesystem.
  43. You must convince us that open() makes sense for everything that might
  44. be a file descriptor, and that it provides a real benefit for future
  45. applications, before you destroy what we see as the beauty and power of
  46. UNIX.
  47.  
  48. ---Dan
  49.  
  50. Volume-Number: Volume 21, Number 128
  51.  
  52.