home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v21 / 187 < prev    next >
Internet Message Format  |  1990-12-05  |  2KB
  1. From jsq@cs.utexas.edu  Fri Oct  5 02:45:38 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA25060; Fri, 5 Oct 90 02:45:38 -0400
  4. Posted-Date: 4 Oct 90 22:34:05 GMT
  5. Received: by cs.utexas.edu (5.64/1.77) 
  6. From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  7. Newsgroups: comp.std.unix
  8. Subject: Unified I/O namespace: what's the point?
  9. Message-Id: <13220@cs.utexas.edu>
  10. Sender: jsq@cs.utexas.edu
  11. Organization: IR
  12. X-Submissions: std-unix@uunet.uu.net
  13. Date: 4 Oct 90 22:34:05 GMT
  14. Reply-To: std-unix@uunet.uu.net
  15. To: std-unix@uunet.uu.net
  16.  
  17. Submitted-by: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
  18.  
  19. We all know that the best standards codify existing practice, while the
  20. worst standards attempt to introduce new features without knowing what
  21. they'll do. For example, POSIX 1003.1 has slaughtered some of my best
  22. code and thrown huge roadblocks into my porting attempts, simply by
  23. adding an unnecessary feature (sessions) that hadn't been proven to work
  24. in the real world. It's a nice standard---except where it enters totally
  25. uncharted territory.
  26.  
  27. Now we're looking at another possible addition to UNIX that hasn't been
  28. widely tested: a unified namespace for opening all I/O objects. But we
  29. already have a unified file descriptor abstraction for reading, writing,
  30. and manipulating those objects, as well as passing them between separate
  31. processes. Why do we need more?
  32.  
  33. I propose that we stop discussing this issue in comp.std.unix and start
  34. implementing real-world solutions. My approach is to separate opening
  35. and connecting into special programs, and stick to file descriptors for
  36. almost all applications. If you have a different solution, such as
  37. overloading open(), why don't you start playing with your library and
  38. seeing what works? 
  39.  
  40. When we have a lot more real-world experience with various solutions,
  41. we can come back here and consider standardization. Until then, ciao.
  42.  
  43. ---Dan
  44.  
  45. Volume-Number: Volume 21, Number 187
  46.  
  47.