kuhn@SWE.NCSL.NIST.GOV (Kuhn) (08/21/89)
Vern Staats posted some questions concerning the proposed NIST FIPS on the
X Window System. I know that others have the same concerns. We at
NIST tried to take these concerns into account in preparing the FIPS
proposal. I'd like to respond to the questions on behalf of NIST.
Rick Kuhn
Technology Bldg. B266
National Institute of Standards and Technology
(formerly National Bureau of Standards)
Gaithersburg, Md. 20899
301/975-3337
DDN: kuhn@swe.ncsl.nist.gov
DRKuhn@dockmaster.ncsc.mil
UUCP: attunix!swe!kuhn
> From: staatsvr@m11.sews.wpafb.af.mil (Vern Staats)
>
> I see that NIST is planning to adopt the X wire protocol, Xlib, and the
> Xt intrinsics as a FIPS PUB, for "network-based bit-mapped graphic system
> applications acquired or internally developed for Federal use, which have
> applications portability as a concern." That's not a direct quote, but
> it's pretty close.
>
> Please note that the focus is on applications portability. They specifically
> state that this FIPS is not intended to specify a government-wide style or
> "look & feel".
>
> If adopted, most applications which fall into the above category would have
> to be based on Xlib and the Xt intrinsics. While this initially struck me
> as a good thing, I do have some questions about including the intrinsics.
> Any answers/feedback/opinions would be greatly appreciated.
>
> 1) They are specifying X11R3. Shouldn't they really spec R4?
Yes, but at the time the proposed FIPS was prepared, R3 was the current
release. R4 should be the official X Consortium standard by the end of this
year. The FIPS approval process will probably take until the end of the year
as well, so we can substitute R4 before the FIPS becomes official.
Furthermore, NIST would like to keep the FIPS consistent with X Consortium
specs in the future.
> 2) Do the benefits of standardization outweigh losing Andrew, Interviews,
> (and others, I'm sure) applications which are not based on the intrinsics?
As with all NIST standards, if this FIPS does not meet the needs of an
agency, the agency is free to choose other technology. So non X-based
solutions would not be lost to developers who need them.
> 3) It seems to me that for true application portability, you would need to
> either stay with Xlib, or standardize all the way up to the widget level.
> Creating a standard foundation for widget sets is all well and good, but
> the application may not be portable if you don't have the right widgets.
> Perhaps they should state that applications not be based on proprietary
> widget sets.
Currently there are no widget standards, from the X Consortium or anyone
else. IEEE P1201 is working toward a standard for an X based toolkit, and
NIST is participating in this effort. In fact, P1201 will base its work on
the FIPS.
> 4) Is ICCCM compliance important to application portability?
Yes, NIST will consider inclusion of ICCCM in an update of the FIPS.
> 5) There seem to be a few differences between the X Consortium intrinsics
> and those provided by DEC. I assume other vendors have "enhanced" their
> intrinsics as well to provide extensions, better performance, etc. The
> departures from the Consortium's intrinsics do not appear to have had
> much impact on applications portability; I can't recall seeing any
> questions on comp.windows.x regarding problems arising from differing
> intrinsics. Am I correct in assuming that most vendors will have little
> difficulty producing compliant applications, even if they normally use
> extended intrinsics?
All vendors have extended the Intrinsics. One of the reasons for the
development of R4 and R4+ is to make the Intrinsics more complete as a
basis for toolkit development. NIST intends to update the FIPS to the
X Consortium specs as they are completed. Vendors who follow the X
Consortium standards will be updating their applications as well. The X
Consortium is committed to making the next version of the Intrinsics source
code compatible with R3.
> 6) I've heard that the X Consortium and X/Open are both opposed to
> standardizing on the Intrinsics at R3 and even at R4. Is this true?
No, it isn't, with respect to the Federal government standardizing on R3
intrinsics. Bob Scheifler, director of the X Consortium, has expressed
his support for adoption of R3 as a FIPS. X/Open has taken no position on
the adoption of R3 as a FIPS. Again, we intend to substitute R4 before the
FIPS becomes official.kuhn@SWE.NCSL.NIST.GOV (Kuhn) (08/22/89)
Correction to my previous posting. In the answer to question 2, please substitute "Xt" for "X": >> 2) Do the benefits of standardization outweigh losing Andrew, Interviews, >> (and others, I'm sure) applications which are not based on the intrinsics >As with all NIST standards, if this FIPS does not meet the needs of an >agency, the agency is free to choose other technology. So non X-based >solutions would not be lost to developers who need them. ------------------------------------------------------------------------------- I'd also like to add to the explanation of what is and is not required by the FIPS. It does not require agencies to write applications that call only Xt and Xlib. It does not prohibit vendors from supplying extensions. At this time there is clearly a need to use both toolkit functions and extensions in applications. The intent of the FIPS is to promote application portability at the source code level. We can do this to some extent now by establishing a common base. It will be possible to a much greater extent when IEEE P1201 completes its standard toolkit API. At that point it will be possible to develop many useful applications using only standard interfaces, but even then some applications will require the use of proprietary extensions or entirely non-standard systems. This is inevitable, and it would be silly to attempt to prohibit it. Allowing the use of extensions and non-standard systems, when necessary, also helps to ensure that standards do not limit innovation. Rick Kuhn