home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.23 / text0045.txt < prev    next >
Encoding:
Text File  |  1991-06-15  |  7.9 KB  |  157 lines

  1. Submitted-by: ahby@uinj.UI.ORG (Shane McCarron)
  2.  
  3. Peter,
  4.  
  5. I need to corrrect one of your points:
  6.  
  7. > The final decision of the SEC (Sponsor Executive Committee), the body
  8. > charged with making a decision about the PARs, was effectively to say:
  9. > at this time, we will not go ahead with accepting the proposals as
  10. > POSIX projects.
  11.  
  12. These would not have been POSIX projects as that term is currently
  13. used.  POSIX projects are those which fall within the IEEE project
  14. 1003.  These would have been under some other project - potentially
  15. P1224 (windowing user interfaces) but that is not certain.  Note that
  16. POSIX projects are candidates for international standardization under
  17. ISO/IEC JTC 1/SC22/WG15.
  18.  
  19.  
  20. > The purpose of this article is to raise this issue in a general forum,
  21. > there are a great number of questions here. There are many possible
  22. > positions that can be taken. I don't want to be seen to prejudge the
  23. > issue by asking too many questions.. so perhaps the topic for debate
  24. > should be
  25. >     Was the decision of the SEC wrong?
  26.  
  27. Personally, I believe the decision of the SEC was the only one they
  28. could make.  The SEC faced perhaps its most difficult decision in
  29. looking at a purely political problem, rather than a technical one.
  30. The goal of the POSIX committees (and now some other projects), as it
  31. was established in 1985, is to increase the viability of open systems
  32. application development through the standardization of open systems
  33. interfaces.
  34.  
  35. The group began concentrating, in 1985, on the standardization of the
  36. low level system interfaces.  Those became available in IEEE Std
  37. 1003.1-1988 (and now 1990).  Those standard interfaces, in conjunction
  38. with the ANSI C Standard, made it possible to develop extremely
  39. portable, but also extremely limited, applications.  It was necessary
  40. to continue creating standards at higher and higher levels of the
  41. application development hierarchy in order to allow the development of
  42. extremely portable, but extremely complex, applications.
  43.  
  44. In reviewing the PARs that were submitted to the SEC, the group had to
  45. consider this goal and how it could be furthered.  Clearly it would
  46. have been irresponsible to standardize multiple interfaces in the same
  47. space, as that would not have promoted application portability.  Also,
  48. it would not have been politically savvy for the SEC to create a
  49. situation where the market would be limited because of an apparent
  50. IEEE endorsement of either of these interfaces singly.
  51.  
  52. This same battle was fought two years ago in the IEEE committee 1224.
  53. This committee was going to produce a X toolkit interface standard.
  54. At that time the group believed that it could define a hybrid
  55. interface that would satisfy the needs of both existing comminuties
  56. while abstracting some of the more obscure concepts of those interfaces to 
  57. make it easier to expand those systems in the future.  This approach, now known
  58. as Look and Feel Independent API development, has been the subject of
  59. a constant battle within the IEEE working group since it began because 
  60. the members of the affected communities do not want to see their markets 
  61. eroded by some sort of hybrid solution that would, in effect, indicate to 
  62. the users that the original interfaces were somehow not perfect.
  63.  
  64. Let me say something heretical here in the hope of raising awareness.
  65. The X Window System is NOT PERFECT.  Further, the existing toolkits
  66. that lie on top of the X Window System are NOT PERFECT.  In fact, they
  67. are so far from perfect that it is not even funny.  The problems lie
  68. in two areas - difficult to use programmatic interfaces and
  69. inconsistent user interfacew style among applications.
  70.  
  71. The programmatic interface problems arise from the fact that the X
  72. Windows System is not layered, and it was not designed (perhaps this
  73. is too strong).  Programmers working within OSF/Motif or OPEN LOOK
  74. must plunge into the depths of the X intrinsics and X lib as well if
  75. they want to have a working application.  The interfaces are inconsistent, 
  76. the interface naming conventions are apocryphal, and the argument passing 
  77. is confusing at best.
  78.  
  79. The concepts of windowing systems are well known, and have been for several 
  80. years.  These include things like pull-down menus, buttons, radio buttons,
  81. slide bars, scroll bars, go-away boxes, double-clicking, dragging,
  82. etc...  These concepts are represented in all of the available windowing 
  83. systems on the market today, although they do not all operate in
  84. exactly the same way.
  85.  
  86. For the last two years two groups within the IEEE have been looking at
  87. the problem of enhancing application protability through the
  88. harmonization of these concepts (driveability) and through the
  89. definition of an API that would layer on top of existing, well known
  90. graphical user interfaces in such a way that truly portable
  91. applications could be developed INDEPENDENT of the underlying
  92. platform.
  93.  
  94. Why is this desirable?  For at least two reasons.  First, no one
  95. should have to work with X.  Applications developers have gained a lot
  96. of experisnce with X, and they can do it if they have to.  Developers
  97. also gained a lot of experience with sockets in their infancy.  That
  98. experience created a series of additional interfaces that eliminted
  99. the need to go through the pain of working with those low level
  100. interfaces.  The X community should benefit from their experience and
  101. work at the level where applications are developed, not at the level
  102. where the network protocol is controlled.
  103.  
  104. The second reason is harder to grasp.  The Open Systems community
  105. needs certain applications if it is to survive the coming war (MS Windows,
  106. OS/2, and the new Compaq/Microsoft/DEC alliance).  Those applications 
  107. are the ones that have sold millions and millions of PCs.
  108. The developers of those applications are not interested in redeveloping
  109. them for a marginal market.  While this may not affect many of you who
  110. are in the research and development community, it has a dramatic
  111. effect on the bottom line of the companies that are driving Open
  112. Systems.  Without these critical personal productivity applications
  113. (Lotus, Microsoft Word, etc...) the market cannot survive.  If the
  114. market collapses, then Open Systems as we know it, based upon a POSIX
  115. system with ANSI C and other layered interfaces, will become something
  116. that is no longer open.  
  117.  
  118. The only way to ensure that these applications become (and remain) available 
  119. on Open Systems platforms is to provide layered interfaces which 
  120. are portable to a number of platforms (the P1224 approach is to
  121. have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK,
  122. and Presentation Manager).  With these interfaces applications developers 
  123. that are already working in the DOS world will find it more reasonable to move
  124. their applications, as it will increase their market effectively for free.  
  125. A single source would port readily and run on POSIX systems, MS-DOS systems, 
  126. and OS/2 Systems.
  127.  
  128. Those are the things that went through my head as I listened to the
  129. debate at the SEC meeting two weeks ago.  I believe that is what a
  130. number of the SEC members were thinking about.  It is crucial that the
  131. community continues to grow in such a way that application developers
  132. are attracted to the platform that we are defining.  If they are not,
  133. then we have failed.
  134.  
  135. Note that one of the criteria that the SEC uses when reviewing a
  136. potential project is whether the standard to be produced would have
  137. a similar level of acceptance to those which have already been
  138. sponsored.  I do not believe that either of the proposed projects
  139. would have reached that level of acceptance (for all of the technical
  140. and political reasons above).  For that reason alone I would have
  141. voted against either PAR.
  142.  
  143. --
  144. Shane P. McCarron
  145. UNIX International Instutional Representative to TCOS-SS SEC
  146. Secretary, TCOS-SS
  147. Chair, TCOS-SS SEC Project Management Subcommittee
  148.  
  149. Note that these are my personal opinions, and do not necessarily represent 
  150. those of my employer or the IEEE.  (I have to say that - the IEEE
  151. insists upon it).
  152.  
  153.  
  154. Volume-Number: Volume 23, Number 49
  155.  
  156.