Opinions on prospective standards sought

[Shane McCarron]

Submitted-by: ahby at 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