home *** CD-ROM | disk | FTP | other *** search
- 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
-
-