home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.21 / text0167.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.0 KB  |  44 lines
  1. Submitted-by: donn@hpfcrn.fc.hp.com (Donn Terry)
  2.  
  3. I was thinking about this a bit more, and want to propose some food for
  4. thought on the issue.
  5.  
  6. Classically, open() is a function that "opens a file descriptor", which
  7. is where the name comes from.
  8.  
  9. However, if you think, rather, of open() as "translate from the (filesystem)
  10. namespace this string, and give me a handle on the object" it actually makes
  11. more sense.
  12.  
  13. The operations that can be performed on a file are the classical operators
  14. applicable to such a handle.  However, some are forbidden or meaningless on 
  15. some object types (lseek on FIFOs, ioctl on ordinary files, some fcntls on
  16. devices), and some have operations only applicable to them (ioctl on 
  17. devices) and no other type.  I can easily imagine an object that had none
  18. of the classical file operations applied to it.
  19.  
  20. Now, there is also nothing that requires that open() be the only function
  21. that returns such a generic object handle.  Imagine (simple example) a
  22. a heirarchical namespace that contains all possible character
  23. bitcodes in the namespace.  Open() would not work very well because of the
  24. null termination and slash rules.  However, I can imagine another function
  25. that takes a char** as an argument, where each element is the name in
  26. the next level of the heirarchy.  (With length in the first byte.)  It
  27. would still return a classical file descriptor.  Similarly, maybe the
  28. punctuation is different, or the notion of "root" is different; generalizing
  29. open() to "give me a handle in a namespace" may be most useful.
  30.  
  31. I intend this not as any sort of proposal of something that should or should
  32. not be done, but as an "icebreaker" in terms of thinking about the problem.
  33.  
  34. What are the further generalizations we need, how do they make sense and
  35. fit together, and (the real test of success) what are some of the unexpected
  36. benefits of the generalization?  (Granting that the "biggest" unexpected
  37. benefit will show up "later".)
  38.  
  39. Donn Terry
  40. Speaking only for myself.
  41.  
  42. Volume-Number: Volume 21, Number 167
  43.  
  44.