home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.17 / text0003.txt < prev    next >
Encoding:
Internet Message Format  |  1990-01-06  |  4.5 KB
  1. From: Kuhn <kuhn@swe.ncsl.nist.gov>
  2.  
  3. Vern Staats posted some questions concerning the proposed NIST FIPS on the
  4. X Window System.  I know that others have the same concerns.  We at
  5. NIST tried to take these concerns into account in preparing the FIPS
  6. proposal.  I'd like to respond to  the questions on behalf of NIST.
  7.  
  8. Rick Kuhn
  9. Technology Bldg.  B266
  10. National Institute of Standards and Technology
  11. (formerly National Bureau of Standards)
  12. Gaithersburg, Md.  20899
  13.  
  14. 301/975-3337
  15.  
  16. DDN:    kuhn@swe.ncsl.nist.gov  
  17.         DRKuhn@dockmaster.ncsc.mil
  18. UUCP:    attunix!swe!kuhn
  19.  
  20.  
  21. > From: staatsvr@m11.sews.wpafb.af.mil (Vern Staats)
  22. > 
  23. > I see that NIST is planning to adopt the X wire protocol, Xlib, and the 
  24. > Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
  25. > applications acquired or internally developed for Federal use, which have 
  26. > applications portability as a concern."  That's not a direct quote, but
  27. > it's pretty close.
  28. > 
  29. > Please note that the focus is on applications portability.  They specifically
  30. > state that this FIPS is not intended to specify a government-wide style or
  31. > "look & feel".
  32. > 
  33. > If adopted, most applications which fall into the above category would have
  34. > to be based on Xlib and the Xt intrinsics.  While this initially struck me 
  35. > as a good thing, I do have some questions about including the intrinsics.
  36. > Any answers/feedback/opinions would be greatly appreciated.
  37. > 
  38. > 1)  They are specifying X11R3.  Shouldn't they really spec R4?
  39.  
  40. Yes, but at the time the proposed FIPS was prepared, R3 was the current 
  41. release.  R4 should be the official X Consortium standard by the end of this 
  42. year.  The FIPS approval process will probably take until the end of the year 
  43. as well, so we can substitute R4 before the FIPS becomes official.  
  44. Furthermore,  NIST would like to keep the FIPS consistent with X Consortium 
  45. specs in the future.
  46.  
  47.  
  48. > 2)  Do the benefits of standardization outweigh losing Andrew, Interviews, 
  49. >     (and others, I'm sure) applications which are not based on the intrinsics? 
  50. As with all NIST standards, if this FIPS does not meet the needs of an
  51. agency, the agency is free to choose other technology.  So non X-based
  52. solutions would not be lost to developers who need them.
  53.  
  54.  
  55. > 3)  It seems to me that for true application portability, you would need to
  56. >     either stay with Xlib, or standardize all the way up to the widget level.
  57. >     Creating a standard foundation for widget sets is all well and good, but
  58. >     the application may not be portable if you don't have the right widgets.
  59. >     Perhaps they should state that applications not be based on proprietary
  60. >     widget sets.
  61.  
  62. Currently there are no widget standards, from the X Consortium or anyone
  63. else.  IEEE P1201 is working toward a standard for an X based toolkit, and
  64. NIST is participating in this effort.  In fact, P1201 will base its work on
  65. the FIPS.
  66.  
  67. > 4)  Is ICCCM compliance important to application portability?
  68.  
  69. Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.
  70.  
  71.  
  72. > 5)  There seem to be a few differences between the X Consortium intrinsics 
  73. >     and those provided by DEC.  I assume other vendors have "enhanced" their
  74. >     intrinsics as well to provide extensions, better performance, etc.  The
  75. >     departures from the Consortium's intrinsics do not appear to have had
  76. >     much impact on applications portability; I can't recall seeing any
  77. >     questions on comp.windows.x regarding problems arising from differing
  78. >     intrinsics.  Am I correct in assuming that most vendors will have little
  79. >     difficulty producing compliant applications, even if they normally use
  80. >     extended intrinsics?
  81.  
  82. All vendors have extended the Intrinsics.  One of the reasons for the
  83. development of R4 and R4+ is to make the Intrinsics more complete as a
  84. basis for toolkit development.   NIST intends to update the FIPS to the 
  85. X Consortium specs as they are completed.  Vendors who follow the X 
  86. Consortium standards will be updating their applications as well.  The X
  87. Consortium is committed to making the next version of the Intrinsics source
  88. code compatible with R3.
  89.  
  90.  
  91. > 6)  I've heard that the X Consortium and X/Open are both opposed to 
  92. >     standardizing on the Intrinsics at R3 and even at R4.  Is this true?
  93.  
  94. No, it isn't, with respect to the Federal government standardizing on R3
  95. intrinsics.  Bob Scheifler, director of the X Consortium, has expressed
  96. his support for adoption of R3 as a FIPS.  X/Open has taken no position on
  97. the adoption of R3 as a FIPS.
  98.  
  99.  
  100. Volume-Number: Volume 17, Number 4
  101.  
  102.  
  103.