staatsvr@asd.wpafb.af.mil (Vern Staats) (08/18/89)
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?
2) Do the benefits of standardization outweigh losing Andrew, Interviews,
(and others, I'm sure) applications which are not based on the intrinsics?
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.
4) Is ICCCM compliance important to application portability?
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?
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?
Thanks again for any info.
If I get mail with points not covered on the net I'll post a summary.
NIST = National Institute of Standards and Technology,
previously the National Bureau of Standards.
FIPS PUB = Federal Information Processing Standards Publication.
See Also: Federal Register / Vol. 54, No. 108 / June 7, 1989, page 24372
and: Mr. D. Richard Kuhn, NIST, Gaithersburg MD 20899, (301) 975-3337.
NIST is soliciting comments until 5 September 1989.
----
"Hundreds of miles apart, the ships inerted and their pilots
fought with supreme skill to make the two intrinsics match."
-- Edward E. Smith, Ph.D.
----
----
INET: staatsvr@asd.wpafb.af.mil Vern Staats (513) 255-2714 /// Save
UUCP: nap1!asd!staatsvr ASD/SCED \\\/// The
Opinions: my!own! WPAFB OH 45433 \XX/ Guruasente@decwrl.dec.com (Paul Asente) (08/18/89)
In article <272@nap1.cds.wpafb.af.mil> staatsvr@asd.wpafb.af.mil (Vern Staats) writes: >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 these different versions (at last all that I know of) are converging gloriously in R4. R3 was the first real release of the intrinsics; it had some problems, most of which will be addressed in R4. R4 is fully source compatible with R3, both for widgets and applications, is binary compatible for sources (i.e. you don't have to recompile to relink), and is even binary compatible for widgets if you've been sufficiently careful. >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? I can't speak for X/Open, but it's certainly not true for the X Consortium. -paul asente asente@decwrl.dec.com decwrl!asente
rws@EXPO.LCS.MIT.EDU (08/18/89)
R4 is fully source
compatible with R3, both for widgets and applications, is binary
compatible for sources (i.e. you don't have to recompile to relink), and
is even binary compatible for widgets if you've been sufficiently careful.
Paul is putting words in my mouth, promising things he can't personally
guarantee, which is a no-no. What is true is that this is a major requirement
for the Intrinsics within the Consortium, and the current draft of the revised
Intrinsics attempts to satisfy it. But review within the Consortium is not yet
complete, nor proof of concept, and there is still a public review to come, and
R4 is not out yet.rws@EXPO.LCS.MIT.EDU (08/18/89)
Any answers/feedback/opinions would be greatly appreciated.
I really doubt most people on this list care about this issue, but I'll give you
a personal opinion.
Please note that comments made in this forum are ultimately pretty useless, what
matters is what NIST hears directly, preferably in written form.
If adopted, most applications which fall into the above category would have
to be based on Xlib and the Xt Intrinsics.
I think this is the only interesting issue about the FIPS. I have heard
conflicting interpretations of the FIPS as to whether Xt is viewed as exclusive
or non-exclusive. I offer you no opinion on this. If you care about this
issue, I suggest you get a clarification from NIST, and them make your reaction
known to them. Independent of how the FIPS is intended, there is the issue
of how the FIPS will actually be used in procurements. For that, you will
simply have to rely on your own experience in the federal sector.
1) They are specifying X11R3. Shouldn't they really spec R4?
This is a malformed question. R4 doesn't exist yet. Perhaps what you mean
is, shouldn't they delay the FIPS until the rumored R4 Intrinsics revision
is out? My opinion is no, they shouldn't wait. A FIPS doesn't happen
overnight. Work on this FIPS was underway before there was any real notion
of an R4 Intrinsics revision. The R3 Intrinsics were adopted as a Consortium
standard, meaning that the Consortium encourages people to use it. The federal
government should not be excluded from this. The fact that a future version of
the Intrinsics might cover a broader base of application development does not
negate the utility of the R3 Intrinsics. A FIPS is not a formal standard (in
the sense of ANSI or ISO). It is relatively straightforward to issue a new
FIPS, covering a later revision. For example, there is a FIPS out on a draft
version of POSIX, which was certainly expected to be revised.
2) Do the benefits of standardization outweigh losing Andrew, Interviews,
(and others, I'm sure) applications which are not based on the intrinsics?
See my comments on exclusive vs. non-exclusive above.
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.
I would strongly disagree that "staying with Xlib" would aid portability. I
think you will find strong agreement among the federal agencies that a standard
widget set is desirable/essential; at least, that's what I heard when attending
one or two of the NIST workshops that led up to this FIPS. However, NIST must
in general strive for consensus positions, and there is at present no consensus
for a standard widget set. There is work going on in this area in IEEE P1201,
but the outcome is far from certain (to my mind).
Perhaps they should state that applications not be based on proprietary
widget sets.
There is no such industrial-strength thing today.
4) Is ICCCM compliance important to application portability?
Sure. Again, this FIPS got started before the ICCCM was really rolling, and
can be revised later. If you feel it's important to include the ICCCM in this
or a later FIPS, make your position known to NIST.
Am I correct in assuming that most vendors will have little
difficulty producing compliant applications, even if they normally use
extended intrinsics?
Since compliance for this FIPS has not (to my knowledge) been defined, that's
rather difficult to answer. Again, I suggest that if you care about this issue,
you ask NIST for clarification.
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?
A FIPS is not a formal standard, it is a goverment standard. I am opposed to
to formal standardization of the R3 Intrinsics, and perhaps even the R4
Intrinsics, because the rules of the game are quite different in terms of
when and how you can revise the specification. But the argument does not apply
to a FIPS.dshr@SUN.COM (David Rosenthal) (08/19/89)
> 4) Is ICCCM compliance important to application portability? > ICCCM compliance is irrelevant to application portability, in the strict sense of taking your program from one machine to another and compiling it, and having it work in isolation (by which I mean both before and after it is the only client connected to its X server). But, of course, this is not a realistic scenario. For a program to be useful after it has been ported, it must coexist properly with the other clients that will be using the X server at the same time. (After all, what is the point of a window system if you can only run one client at a time?). And it is this inter-operability that conforming to the ICCCM is intended to provide. The goal of the ICCCM is that a conforming client should inter-operate correctly with any conforming window manager, and should communicate data through the selection mechanism with any other conforming client. If you don't allow your users to choose their own window manager, and you don't care about supporting cut-and-paste between clients, then the ICCCM conventions don't affect your definition of portability. But I doubt that this is many people's definition. X is a network window system, and this means that if a client is available on any machine on the net it is potentially usable by any X workstation or terminal on the same net. Thus, there is a strong case for arguing that the inter-operability of the ICCCM is a much more important consideration than portability. Inter-operating with a program is going to be MUCH cheaper than porting it, and its probably going to be done a lot more often. David.