From: matt@centerline.com (Matt Landau)
Newsgroups: comp.windows.open-look
Subject: Re: SunSoft Windows Toolkits Positioning
Date: 19 Nov 1992 18:27:14 GMT
Organization: CenterLine Software, Inc.
Distribution: comp
NNTP-Posting-Host: 140.239.1.32

In <PREECE.92Nov19092817@predator.urbana.mcd.mot.com> preece@urbana.mcd.mot.com (Scott E. Preece) writes:
>We have had technical contributions from people associated
>with XVT, Galaxy, both OIs, Wndex, Wcl, THINGS, TAE+, and others;
>a subset of the XVT API is our base document, but several of the other
>toolkit APIs are reference documents and we are trying very hard to be
>inclusive.  

Does this imply that the "standard" is going to include several different, 
and mutually incompatible, API's among its base and reference documents?  
What's the point?

>Ironically, with respect to this discussion, we are working on a
>language-independent API specified as objects and attributes, very much
>in the style of XView (though we have cut our objects somewhat
>differently).

Sounds a lot like some components of Project DOE as well.

>standards to be important.  The government, of course, also supports
>open systems and NIST has issued an Application Portability Profile that
>suggests using a platform independent toolkit for portability.  A NIST
>staffer is a regular participant in the P1201.1 work group, as are
>several people sent by very large corporations who support open systems.

Yes, but a "standard" that includes three or more different API's seems
to serve no purpose whatsover beyond letting some vendor certify to the
government that its toolkit or application "conforms to the standard";
the fact that such a standard is largely meaningless outside its value 
in the bureaucratic realm of government purchasing paperwork seems not 
to concern the standards bodies at all.  

It's like putting two lawyers in a room together -- sure, they'll make 
work for each other, but is that really a worthy goal in itself?

>that the Windows/Macintosh model of the application with local display
>capability only is the long-term winner.  Xt may not be the answer (I
>personally find Xt a peculiarly unattractive way of expressing
>programs), but APIs that require a kernel-based, local-display
>implementation aren't, either.

API's should have NOTHING to say about whether display implementations
are local and kernel-based, remote and server-based, or some combination
of the two.  A good API should provide a useful, portable way to talk to
different display systems and input systems.  

We can argue about what constitutes "portable" and "useful", and indeed
that's one of the things standards bodies should be doing.  Personally,
I find the X11 imaging model to be neither, which concerns me even more
than the rather widely acknowledged shortcomings of the Xt Intrinsics
architecture.

In any case, an API should specify how you talk to the display and input
systems -- the details of how the display actually works, and where the
input actually comes from [the keyboard on your desk, the mouse on the
other side of the continent, or the laser-guided pointer device on the 
surface of the moon] shouldn't have to affect the programming interface.
--
 Matt Landau			Waiting for a flash of enlightenment
 matt@centerline.com			  in all this blood and thunder
Newsgroups: comp.windows.open-look,alt.toolkits.xview