home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.21 / text0192.txt < prev    next >
Encoding:
Text File  |  1990-10-26  |  2.7 KB  |  57 lines
  1. Submitted-by: ske@pkmab.se (Kristoffer Eriksson)
  2.  
  3. In article <13220@cs.utexas.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
  4. >Now we're looking at another possible addition to UNIX that hasn't been
  5. >widely tested: a unified namespace for opening all I/O objects.
  6. >
  7. >I propose that we stop discussing this issue in comp.std.unix and start
  8. >implementing real-world solutions.
  9.  
  10. I am already running a system where a file name can lead to any kind of
  11. I/O object. It works fine, as far as I can judge. What more should I do?
  12.  
  13. (Not everything that could be is implemented via file names in this system,
  14. but there are networks and databases that are interfaced via this mechanism,
  15. and I like it a lot. Server programs attach themselves to directory or file
  16. names, and will take care of all file operations attempted by clients on
  17. this file or directory.)
  18.  
  19. > My approach is to separate opening and connecting into special programs,
  20. >and stick to file descriptors for almost all applications.
  21.  
  22. Doesn't your objection about the semantics of open() on network connections
  23. fall down in that case? Do your special programs for obtaining the file
  24. descriptors make the real semantics of network connections available to
  25. the application any more than open() does?
  26.  
  27. I think file names are more useful. How do you for instance stick a file
  28. descriptor that you obtained by one of your special programs into the
  29. configuration file for some program? File names are readily suitable for
  30. that. If you just stick the network address into the file, the application
  31. will be restricted to network connections (maybe only one type of network,
  32. at that), and the application will have to know how to access that kind of
  33. connection.
  34.  
  35. > If you have a different solution, such as
  36. >overloading open(), why don't you start playing with your library and
  37. >seeing what works? 
  38.  
  39. Too static. You will in practice be conserving the top level of the name
  40. space inside your library routines. With non-shared libraries this would
  41. mean you'ld have to recompile all your programs if you need to change
  42. what kind of objects you can access or how they are accessed. With chared
  43. libraries this only requires recompiling the libraries, but still isn't
  44. something you'ld like to do every day. With the entire name space available
  45. through the filesystem, you can change the entire hierarchy dynamically,
  46. and starting the server for some kind of objects may as part of that same
  47. operation establish the access path (just a file name) through which it is
  48. accessed.
  49. -- 
  50. Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
  51. Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
  52. Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
  53.  
  54.  
  55. Volume-Number: Volume 21, Number 193
  56.  
  57.