home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / osf / misc / 84 next >
Encoding:
Internet Message Format  |  1993-01-21  |  3.2 KB
  1. Path: sparky!uunet!spool.mu.edu!yale.edu!ira.uka.de!Germany.EU.net!materna!tb
  2. From: tb@Materna.DE (Torsten Beyer)
  3. Newsgroups: comp.unix.osf.misc
  4. Subject: Re: Future of DCE?
  5. Message-ID: <tb.727603438@materna>
  6. Date: 21 Jan 93 08:03:58 GMT
  7. References: <C0vyon.619@volvo.volvo.se> <80@mhinfo.UUCP>,     <tb.727360590@materna> <kfL5tYr0BwxI5janUu@transarc.com>
  8. Sender: root@maternaMaterna.DE
  9. Lines: 56
  10.  
  11. Craig_Everhart@transarc.com writes:
  12.  
  13. >Nobody can predict the future very well, and you're talking about
  14. >projects of very different levels of maturity in the same breath (Motif,
  15. >DME).  DME is the newest project on the plate.
  16.  
  17. True, but what I meant to say was: Although I personally prefer systems
  18. based on an open development process (whatever that may be in detail, let's
  19. just assume, OSF works that way :-), the problem with these types of
  20. products is that their fate depends not on just one vendor (as is the case
  21. with proprietary systems) but on a whole bunch of them. This makes
  22. prediction of whatever road they might follow even harder.
  23.  
  24. >I imagine that different vendors will do different things with DCE, yet
  25. >retain compatibility.  Whether it makes its way back to ``the original
  26. >DCE source'' is another matter, and basically solely up to the OSF.  In
  27.  
  28. My fear is that Version X of any OSF product is basically the root of tree
  29. of different products, each claiming to be OSF/X compliant but in fact the
  30. products move away from each other. If they move so far as to not even
  31. interoperable with each other I don't know, but that might be a severe
  32. thread.
  33.  
  34. >Clearly, you accept the ``Sun next door'' as a reference platform for
  35.  
  36. That to me sounds too positive. It's not that I accept the Sun next door as
  37. the right means of verifying protocols. But as you say, TCP/IP is so
  38. widespread that from a practical standpoint to veryfy X's TCP/IP port you
  39. can virtually use any system next door to prove interoperabiltiy. I very
  40. aware that this wasn't the case maybe 7 years ago. But the situation has
  41. changed in some way. TCP/Ip was new. There wasn't much else to build
  42. heterogeneous networks. Today we have an awful lot of tools and protocols
  43. intended to help us build and maintain these networks (wether they succeed
  44. is a different question altogether :-). Now here comes OSF and tells us, to
  45. throw away this old rubbish and start usin their stuff. I'd rather like to,
  46. but then how much do I pay for it. I certainly can't check X's DCE
  47. implementation as easy as I can with a plain and easy ONC-RPC
  48. implementation. I have to buy validation suites and all that. It clearly is
  49. a spinnoff problem. As soon as the number of available DCE implementations
  50. exceeds a critical mass, we'll see the same situation as with TCP/IP. 
  51.  
  52. >I'm sure that there will be companies like that around, but indeed the
  53. >stuff should just work (well, mostly).
  54.  
  55. Hmm, from what you write I guess you have been in this business for quite
  56. some time. You should know, that every sentence containing the phrase
  57. "should work", simply means it doesn't :-)))))
  58.  
  59.  
  60.  
  61.             -Torsten
  62. --
  63. Torsten Beyer                          mail         : tb@Materna.DE
  64. Dr. Materna GmbH               vox humana   : +49 231 5599 225
  65. Vosskuhle 37, D-4600 Dortmund           fax machina  : +49 231 5599 100
  66.    "Once in a moment the SUN goes down, protect and survive" -- Runrig
  67.