home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0013.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  3.3 KB  |  65 lines
  1. Submitted-by: ahby@ui.org (Shane McCarron)
  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. Note that the XOM interface is NOT an object management interface
  11. (regardless of what the title says).  It is just a set of interfaces
  12. for manipulating opaque data types across a network of heterogeneous
  13. systems.  If you called it XDR you wouldn't be far from correct.
  14. Certainlky XDR is extensible, so logically XOM could be too.  However,
  15. XOM isn't designed to be extensible, and XDR is.  XOM is designed to
  16. solve an extremely specific problem - and by all accounts it solves
  17. that problem.
  18.  
  19. > My other objection was that the XDS/XOM user will be presented with a
  20. > different "standard compliant" interface by each vendor *AND* it is left as an
  21. > exercise for the user to "impedance match" between them.  This is not a
  22. > standard by any definition I know.  The vendor gets to declare POSIX standard
  23. > compliance and the the user has been left with the task of defining and
  24. > implementing a common interface on top of different vendor-specific
  25. > implementations.  Huh?  (Unless, of course, the user only uses one vendor but
  26. > in this case we have a degenerate standard ... one thing is always exactly
  27. > like itself whatever the thing is!).
  28.  
  29. I don't understand this contention.  It is impossible to present a
  30. different standard compliant interface  - the language bindings are
  31. the standard, and they are being specified by the committee.  Also,
  32. note that the XOM activity is NOT a POSIX standard.  Frankly, the XDS
  33. activity shouldn't be either, but we haven't fixed taht yet.  XOM is
  34. P1224 - only P1003 committees are POSIX.
  35.  
  36. > But, vendor incompatibility is exactly what XOM provides.  Thus, I seems to me
  37. > that the base technology that X/Open is trying to hustle through POSIX (XDS
  38. > and XOM) violates its own charter never mind the spirit of POSIX.
  39.  
  40. Again, I don't understand this.  The underlying protocols for XDS are
  41. defined by X.500, so communication between machines will work.  XOM
  42. just provides interfaces to encode C language specific data types in
  43. ways that are compatible across the network (unless I am very much
  44. mistaken - that happens sometimes).
  45.  
  46. > Actually, I wouldn't be worrying so much if XOM were just a bunch of helper
  47. > routines at the bottom of XDS and X.400.  But the fact is that name space
  48. > management (threads, files, you name it) is the name of the game.  XOM could
  49. > be trotted out as a good way to manage names everywhere in POSIX and indeed it
  50. > might be.  But not if it locks names away in lots of little bunkers to which
  51. > only the vendors have the keys.
  52.  
  53. XOM will never be promoted as a generalized namespace manager,
  54. especially not for things within POSIX.  It is not a POSIX service.
  55. Generalized namespace management will have to wait for some
  56. interesting consortia based work to mature (e.g. DCE).
  57.  
  58. -- 
  59. Shane P. McCarron            ATT:    +1 201 263-8400 x232
  60. Project Manager                UUCP:    s.mccarron@ui.org
  61.  
  62.  
  63. Volume-Number: Volume 24, Number 15
  64.  
  65.