pc@hillside.co.uk (Peter Collinson) (04/23/91)
Submitted-by: pc@hillside.co.uk (Peter Collinson) The IEEE POSIX meeting last week had one great topic, or in fact, two, depending on your point of view. OSF had sent in a request to be allowed to create a standard based on Motif. The request is technically called a PAR - a Project Authorization Request. Not to be outdone and with great regret, Sun sent in a PAR for a standard based on OpenLook. Both of these requests were interesting in that the standard was to be created by `direct ballot' (no acronym as yet :-)). This means that a working group will not come into existence to discuss the ins and outs of the technical content. Someone will create a `standards document' from existing documentation and this new document will form the basis of the standard. The draft document then enters the normal balloting process. The final decision of the SEC (Sponsor Executive Committee), the body charged with making a decision about the PARs, was effectively to say: at this time, we will not go ahead with accepting the proposals as POSIX projects. If this resume is wrong, I would be grateful for correction. The purpose of this article is to raise this issue in a general forum, there are a great number of questions here. There are many possible positions that can be taken. I don't want to be seen to prejudge the issue by asking too many questions.. so perhaps the topic for debate should be Was the decision of the SEC wrong? Peter Collinson Usenix Standards Representative [ Peter told me he was tempted to post this to ieee.org as well, and I was tempted to place followup's there. However, as long as any discussion this generates relates mostly to how it will affect unix standards, I will keep it here. -- mod ] Volume-Number: Volume 23, Number 37
henry@zoo.toronto.edu (Henry Spencer) (04/24/91)
Submitted-by: henry@zoo.toronto.edu (Henry Spencer) In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes: >at this time, we will not go ahead with accepting the proposals as >POSIX projects. > ... > Was the decision of the SEC wrong? No, it was precisely right. IEEE and its minions very badly need to exercise a bit more judgement about what gets pursued as a standard. This was a step in the right direction. It is a travesty to produce a "standard" for each manufacturer's different solution to the same problem, the more so by the "direct ballot" (translation: "do it our way, papa knows best") route. It is far more important to standardize things on which there genuinely is consensus. There is also the entirely separate issue that many people (e.g. me) feel that *any* standard in this area is premature, since we just don't understand it well enough yet. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry Volume-Number: Volume 23, Number 38
epstein@trwacs.uucp (Jeremy Epstein) (04/24/91)
Submitted-by: epstein@trwacs.uucp (Jeremy Epstein) In article <130193@uunet.UU.NET>, pc@hillside.co.uk (Peter Collinson) writes: > Submitted-by: pc@hillside.co.uk (Peter Collinson) > > OSF had sent in a request to be allowed to create a standard based on > Motif. The request is technically called a PAR - a Project > Authorization Request. Not to be outdone and with great regret, Sun > sent in a PAR for a standard based on OpenLook. > > [stuff deleted] > > The final decision of the SEC (Sponsor Executive Committee), the body > charged with making a decision about the PARs, was effectively to say: > at this time, we will not go ahead with accepting the proposals as > POSIX projects. I was at POSIX, but (fortunately) missed the SEC meeting. [I was told that the Motif v. OPEN LOOK battle lasted for about six hours!] Since Peter asked for comments, I think the SEC made the right decision. I don't know their rationale, but I see no purpose to two (mutually incompatible) standards which cover the same general area. As a developer, this gives me virtually no help. I'd also like to point out that both OPEN LOOK and Motif are relatively young (only a few years old), and that it's probably a good idea to get more market acceptance before trying to standardize. Finally, I'd suggest that direct ballot is really not a good idea for things which are still quite controversial (i.e., look & feel, applications interfaces). Now that I've displayed my ignorance of the subject...Peter, can you post a summary of the SEC's rationale in rejecting the PARs? That may help channel this discussion. --Jeremy -- Jeremy Epstein UUCP: uunet!trwacs!epstein Trusted X Research Group Internet: epstein@trwacs.fp.trw.com TRW Systems Division Voice: +1 703/876-8776 Fairfax Virginia Volume-Number: Volume 23, Number 39
gwyn@smoke.brl.mil (Doug Gwyn) (04/24/91)
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn) In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes: > Was the decision of the SEC wrong? Without knowing their reasoning, it would be impossible to say. I will say that this whole business of "software standards" has gotten way out of hand, and in general resistance to creating an official standard by rubber-stamping products should be applauded. [ Note followups. -- mod ] Volume-Number: Volume 23, Number 42
gerwitz@hpcore.uucp (Paul Gerwitz) (04/24/91)
Submitted-by: gerwitz@hpcore.uucp (Paul Gerwitz) In article <130193@uunet.UU.NET>, pc@hillside.co.uk (Peter Collinson) writes: |> Submitted-by: pc@hillside.co.uk (Peter Collinson) |> |> The final decision of the SEC (Sponsor Executive Committee), the body |> charged with making a decision about the PARs, was effectively to say: |> at this time, we will not go ahead with accepting the proposals as |> POSIX projects. |> |> Was the decision of the SEC wrong? |> |> Peter Collinson |> Usenix Standards Representative |> I feel the SEC was correct. No reputable standards body should be party to any requests of this type. This particular action by OSF and Sun(UI) demonstrates the lack of integrity both organizations possess as far as promoting their various views. The standards process is meant to come up with a consensus of TECHNICAL merits for a given technolgy. What has been demonstrated by these two groups through their marketing as well as the reports I have seen from IEEE 1204 is that they are unwilling to debate the TECHNICAL issues in an open forum. Such debate would produce a standard which would be better than anything either can offer alone. And isn't the standards process really for the benefit of the users, not the suppliers? This manuvering doesn't seem to further the users goals or needs, but simply gives the supplier another feather for the marketing cap. -- +----------------------------------------------------------------------------+ | Paul F Gerwitz WA2WPI | SMTP: gerwitz@kodak.com | | Eastman Kodak Co | UUCP: ..uunet!atexnet!kodak!eastman!gerwitz | +----------------------------------------------------------------------------+ Volume-Number: Volume 23, Number 41
richard@aiai.ed.ac.uk (Richard Tobin) (04/24/91)
Submitted-by: richard@aiai.ed.ac.uk (Richard Tobin) In article <130193@uunet.UU.NET> pc@hillside.co.uk (Peter Collinson) writes: >OSF had sent in a request to be allowed to create a standard based on >Motif. >Sun sent in a PAR for a standard based on OpenLook. >The final decision of the SEC (Sponsor Executive Committee), the body >charged with making a decision about the PARs, was effectively to say: >at this time, we will not go ahead with accepting the proposals as >POSIX projects. > Was the decision of the SEC wrong? I am delighted to hear of this sensible decision. I cannot see any need for either Open Look or Motif to be standardised. Both are controlled by groups who should be quite capable of ensuring portability. It is of course in the interests of their respective proponents to try and make each "more standard" than the other, but it is not in the interests of users. Eliminating the inconvenient differences and codifying the common ground between variants of Unix on the other hand is a worthwhile project that if done well will be of enormous benefit to users. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin Volume-Number: Volume 23, Number 40
randall@Virginia.EDU (Ran Atkinson) (04/25/91)
Submitted-by: randall@Virginia.EDU (Ran Atkinson)
I agree with what Henry Spencer said in his posting.
To wit:
1) The IEEE shouldn't be in the business of rubber-stamping
vendor-specific or otherwise proprietary "standards."
2) The OpenLook & Motif proposals were political rather than technical,
being made chiefly to add another item for marketing types to use
for disinformation.
3) Not enough is known about user interface design for the area
to be standardised at this time, more experience and research
is both needed and underway. The POSIX efforts should be
focused on standardising good existing practice in well
understood areas only.
I think the SEC did the right thing.
Randall Atkinson
randall@Virginia.EDU
Volume-Number: Volume 23, Number 43barmar@think.uucp (Barry Margolin) (04/25/91)
Submitted-by: barmar@think.uucp (Barry Margolin)
I think the SEC's decision was good. First, for all of the reasons that
others have mentioned. Second, because I'm not sure that IEEE P1003 is the
appropriate umbrella standards organization for Motif or OpenLook. ANSI
X3H3.6 is standardizing window systems (X3H3 is the technical committee on
computer graphics) and GUIs (I think Xlib is currently on their agenda). I
was under the impression (perhaps mistaken) that Motif and OpenLook are
intended to be portable beyond just Unix, so it would be inappropriate to
standardize them as part of POSIX.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmar
Volume-Number: Volume 23, Number 44lewine@cheshirecat.webo.dg.com (Donald Lewine) (04/25/91)
Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine)
|> Was the decision of the SEC wrong?
Well, the SEC took away my chance to vote NO!
Given that no POSIX standard has made it through the ballot
process without major changes, the thought of forcing OSF and
AT&T to fix some of the larger crocks, has some merit. Also,
the thought of both draft standards going down to flaming defeat
and generating a published list of objections seems nice.
Seriously, I think the SEC made the only decision possible. I
don't know why it took 6 hours.
--------------------------------------------------------------------
Donald A. Lewine (508) 870-9008 Voice
Data General Corporation (508) 366-0750 FAX
4400 Computer Drive. MS D112A
Westboro, MA 01580 U.S.A.
uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
Volume-Number: Volume 23, Number 45ahby@uinj.UI.ORG (Shane McCarron) (04/29/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) Peter, I need to corrrect one of your points: > The final decision of the SEC (Sponsor Executive Committee), the body > charged with making a decision about the PARs, was effectively to say: > at this time, we will not go ahead with accepting the proposals as > POSIX projects. These would not have been POSIX projects as that term is currently used. POSIX projects are those which fall within the IEEE project 1003. These would have been under some other project - potentially P1224 (windowing user interfaces) but that is not certain. Note that POSIX projects are candidates for international standardization under ISO/IEC JTC 1/SC22/WG15. > The purpose of this article is to raise this issue in a general forum, > there are a great number of questions here. There are many possible > positions that can be taken. I don't want to be seen to prejudge the > issue by asking too many questions.. so perhaps the topic for debate > should be > > Was the decision of the SEC wrong? Personally, I believe the decision of the SEC was the only one they could make. The SEC faced perhaps its most difficult decision in looking at a purely political problem, rather than a technical one. The goal of the POSIX committees (and now some other projects), as it was established in 1985, is to increase the viability of open systems application development through the standardization of open systems interfaces. The group began concentrating, in 1985, on the standardization of the low level system interfaces. Those became available in IEEE Std 1003.1-1988 (and now 1990). Those standard interfaces, in conjunction with the ANSI C Standard, made it possible to develop extremely portable, but also extremely limited, applications. It was necessary to continue creating standards at higher and higher levels of the application development hierarchy in order to allow the development of extremely portable, but extremely complex, applications. In reviewing the PARs that were submitted to the SEC, the group had to consider this goal and how it could be furthered. Clearly it would have been irresponsible to standardize multiple interfaces in the same space, as that would not have promoted application portability. Also, it would not have been politically savvy for the SEC to create a situation where the market would be limited because of an apparent IEEE endorsement of either of these interfaces singly. This same battle was fought two years ago in the IEEE committee 1224. This committee was going to produce a X toolkit interface standard. At that time the group believed that it could define a hybrid interface that would satisfy the needs of both existing comminuties while abstracting some of the more obscure concepts of those interfaces to make it easier to expand those systems in the future. This approach, now known as Look and Feel Independent API development, has been the subject of a constant battle within the IEEE working group since it began because the members of the affected communities do not want to see their markets eroded by some sort of hybrid solution that would, in effect, indicate to the users that the original interfaces were somehow not perfect. Let me say something heretical here in the hope of raising awareness. The X Window System is NOT PERFECT. Further, the existing toolkits that lie on top of the X Window System are NOT PERFECT. In fact, they are so far from perfect that it is not even funny. The problems lie in two areas - difficult to use programmatic interfaces and inconsistent user interfacew style among applications. The programmatic interface problems arise from the fact that the X Windows System is not layered, and it was not designed (perhaps this is too strong). Programmers working within OSF/Motif or OPEN LOOK must plunge into the depths of the X intrinsics and X lib as well if they want to have a working application. The interfaces are inconsistent, the interface naming conventions are apocryphal, and the argument passing is confusing at best. The concepts of windowing systems are well known, and have been for several years. These include things like pull-down menus, buttons, radio buttons, slide bars, scroll bars, go-away boxes, double-clicking, dragging, etc... These concepts are represented in all of the available windowing systems on the market today, although they do not all operate in exactly the same way. For the last two years two groups within the IEEE have been looking at the problem of enhancing application protability through the harmonization of these concepts (driveability) and through the definition of an API that would layer on top of existing, well known graphical user interfaces in such a way that truly portable applications could be developed INDEPENDENT of the underlying platform. Why is this desirable? For at least two reasons. First, no one should have to work with X. Applications developers have gained a lot of experisnce with X, and they can do it if they have to. Developers also gained a lot of experience with sockets in their infancy. That experience created a series of additional interfaces that eliminted the need to go through the pain of working with those low level interfaces. The X community should benefit from their experience and work at the level where applications are developed, not at the level where the network protocol is controlled. The second reason is harder to grasp. The Open Systems community needs certain applications if it is to survive the coming war (MS Windows, OS/2, and the new Compaq/Microsoft/DEC alliance). Those applications are the ones that have sold millions and millions of PCs. The developers of those applications are not interested in redeveloping them for a marginal market. While this may not affect many of you who are in the research and development community, it has a dramatic effect on the bottom line of the companies that are driving Open Systems. Without these critical personal productivity applications (Lotus, Microsoft Word, etc...) the market cannot survive. If the market collapses, then Open Systems as we know it, based upon a POSIX system with ANSI C and other layered interfaces, will become something that is no longer open. The only way to ensure that these applications become (and remain) available on Open Systems platforms is to provide layered interfaces which are portable to a number of platforms (the P1224 approach is to have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK, and Presentation Manager). With these interfaces applications developers that are already working in the DOS world will find it more reasonable to move their applications, as it will increase their market effectively for free. A single source would port readily and run on POSIX systems, MS-DOS systems, and OS/2 Systems. Those are the things that went through my head as I listened to the debate at the SEC meeting two weeks ago. I believe that is what a number of the SEC members were thinking about. It is crucial that the community continues to grow in such a way that application developers are attracted to the platform that we are defining. If they are not, then we have failed. Note that one of the criteria that the SEC uses when reviewing a potential project is whether the standard to be produced would have a similar level of acceptance to those which have already been sponsored. I do not believe that either of the proposed projects would have reached that level of acceptance (for all of the technical and political reasons above). For that reason alone I would have voted against either PAR. -- Shane P. McCarron UNIX International Instutional Representative to TCOS-SS SEC Secretary, TCOS-SS Chair, TCOS-SS SEC Project Management Subcommittee Note that these are my personal opinions, and do not necessarily represent those of my employer or the IEEE. (I have to say that - the IEEE insists upon it). Volume-Number: Volume 23, Number 49
ahby@uinj.UI.ORG (Shane McCarron) (04/29/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) > I feel the SEC was correct. No reputable standards body should be party to > any requests of this type. This particular action by OSF and Sun(UI) > demonstrates the lack of integrity both organizations possess as far as > promoting their various views. I agree wholeheartedly, but would stress that UI had nothing to do with the OPEN LOOK PAR, and that we actively opposed it within the SEC. UI did offer our User Interface work group to act as ballot arbiters, should a ballot occur. This was done at the request of our member Sun Microsystems, and because we believed that a neutral organization would do a better job of reviewing ballot objections. > The standards process is meant to come up > with a consensus of TECHNICAL merits for a given technolgy. What has been > demonstrated by these two groups through their marketing as well as the > reports I have seen from IEEE 1204 is that they are unwilling to debate the > TECHNICAL issues in an open forum. Such debate would produce a standard > which would be better than anything either can offer alone. And isn't the > standards process really for the benefit of the users, not the suppliers? > This manuvering doesn't seem to further the users goals or needs, but > simply gives the supplier another feather for the marketing cap. Precisely! -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: s.mccarron@ui.org Volume-Number: Volume 23, Number 50
ahby@uinj.UI.ORG (Shane McCarron) (04/29/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) > > Submitted-by: barmar@think.uucp (Barry Margolin) > > I think the SEC's decision was good. First, for all of the reasons that > others have mentioned. Second, because I'm not sure that IEEE P1003 is the > appropriate umbrella standards organization for Motif or OpenLook. ANSI > X3H3.6 is standardizing window systems (X3H3 is the technical committee on > computer graphics) and GUIs (I think Xlib is currently on their agenda). I > was under the impression (perhaps mistaken) that Motif and OpenLook are > intended to be portable beyond just Unix, so it would be inappropriate to > standardize them as part of POSIX. Actually, X3H3.6 has requested that TCOS take Xlib and anything above that layer because they aren't going to get to it (my understanding). However, I agree that 1003 is not the appropriate place. 1224 on the other hand may be appropriate for higher level GUI interfaces. -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: s.mccarron@ui.org Volume-Number: Volume 23, Number 51
ahby@uinj.UI.ORG (Shane McCarron) (04/29/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) > Submitted-by: lewine@cheshirecat.webo.dg.com (Donald Lewine) > > |> Was the decision of the SEC wrong? > > Well, the SEC took away my chance to vote NO! > > Given that no POSIX standard has made it through the ballot > process without major changes, the thought of forcing OSF and > AT&T to fix some of the larger crocks, has some merit. Also, > the thought of both draft standards going down to flaming defeat > and generating a published list of objections seems nice. While I agree with this sentiment, the scope of both PARs was such that objections that would cause the interfaces to change substantially would have been considered unresponsive! At least, that's how I understood it. > Seriously, I think the SEC made the only decision possible. I > don't know why it took 6 hours. Because everyone had to say something, and because some of the people who proposed the PARs really wanted them to go through. There was a lot of screaming and gnashing of teeth. Having said that, as secretary of the SEC I can tell you that most of the debate wasn't interesting enough to be minuted. -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: s.mccarron@ui.org Volume-Number: Volume 23, Number 52
ahby@uinj.UI.ORG (Shane McCarron) (04/30/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) Peter Collinson writes: > Someone asked me to post the `resolution' that was passed - can you > pull it from your notes - or post it as Secretary? There was quite of bit of parlimentary mumbo jumbo that no one cares about. The substance of the resolution was "Resolve that the TCOS-SS SEC does not feel at this time that it should sponsor either the Modular Toolkit Environment PAR or the Open Toolkit Environment PAR." This resolution was adopted. -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: s.mccarron@ui.org Volume-Number: Volume 23, Number 54
ahby@uinj.UI.ORG (Shane McCarron) (04/30/91)
Submitted-by: ahby@uinj.UI.ORG (Shane McCarron) Peter da Silva writes: > > are portable to a number of platforms (the P1224 approach is to > > have a layered API which would work on MS-DOS, OSF/Motif, OPEN LOOK, > > and Presentation Manager). > > How about MacOS/Finder, GEM, and Intuition? I believe that MacOS/Finder was included. GEM and Intuition were not, as far as I know. Could someone else from 1201 address this? > Does your API require the application to manage its own refresh events, > or is that stuff hidden far enough in the library that windowing systems > that handle that sort of thing through backing store won't lose out? The whole point of a LaFI API is that the policies of the underlying GUI are hidden from the application developer. That should all sort os the autonomic behaviors that windowing systems have (just as the human body breathes and pumps blood without conscious effort). -- Shane P. McCarron ATT: +1 201 263-8400 x232 Project Manager UUCP: s.mccarron@ui.org Volume-Number: Volume 23, Number 55