home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0012.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.2 KB  |  45 lines
  1. Submitted-by: guthery@ASC.SLB.COM
  2.  
  3. Andy Hume fairly summarizes part of my objection to the tack that P1003.17 and
  4. P1224 are taking with respect to objects; viz. that vendors can extend whereas
  5. users cannot.  I agree with Andy that extension is not, as Ezno suggests,
  6. "technically infeasible".  Andy points to one possibility.  There are clearly
  7. others.  Lisp and Smalltalk systems have been doing this for years so we know
  8. it can be done. (We're talking existence, folks, not efficiency.)
  9.  
  10. My other objection was that the XDS/XOM user will be presented with a
  11. different "standard compliant" interface by each vendor *AND* it is left as an
  12. exercise for the user to "impedance match" between them.  This is not a
  13. standard by any definition I know.  The vendor gets to declare POSIX standard
  14. compliance and the the user has been left with the task of defining and
  15. implementing a common interface on top of different vendor-specific
  16. implementations.  Huh?  (Unless, of course, the user only uses one vendor but
  17. in this case we have a degenerate standard ... one thing is always exactly
  18. like itself whatever the thing is!).
  19.  
  20. Interestingly, P1003.17 and P1224 are being driven by X/Open.  X/Open's
  21. own Long Term Vision states:
  22.  
  23.     "An environment in which users have access to all of the information
  24.      needed to carry out their job, without contstraints imposed by
  25.                                         ===============================
  26.      incompatibility of technology or data."
  27.          =====================================
  28.  
  29. But, vendor incompatibility is exactly what XOM provides.  Thus, I seems to me
  30. that the base technology that X/Open is trying to hustle through POSIX (XDS
  31. and XOM) violates its own charter never mind the spirit of POSIX.
  32.  
  33. Actually, I wouldn't be worrying so much if XOM were just a bunch of helper
  34. routines at the bottom of XDS and X.400.  But the fact is that name space
  35. management (threads, files, you name it) is the name of the game.  XOM could
  36. be trotted out as a good way to manage names everywhere in POSIX and indeed it
  37. might be.  But not if it locks names away in lots of little bunkers to which
  38. only the vendors have the keys.
  39.  
  40.                             Cheers, Scott
  41.  
  42.  
  43. Volume-Number: Volume 24, Number 14
  44.  
  45.