Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!uunet.UU.NET!sef From: ahby@uinj.UI.ORG (Shane McCarron) Newsgroups: comp.std.unix Subject: Re: Opinions on prospective standards sought Message-ID: <130889@uunet.UU.NET> Date: 29 Apr 91 13:02:41 GMT References: <130193@uunet.UU.NET>; Sender: usenet@uunet.UU.NET Lines: 155 Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix) Nntp-Posting-Host: uunet.uu.net X-Submissions: std-unix@uunet.uu.net Originator: sef@uunet.UU.NET 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