Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-sdd!hp-pcd!hpcvlx!ben
From: ben@hpcvlx.cv.hp.com (Benjamin Ellsworth)
Newsgroups: comp.windows.x
Subject: Re: Abstracting the Windowing System Interface
Message-ID: <100920160@hpcvlx.cv.hp.com>
Date: 2 Feb 90 01:22:32 GMT
References: <200@esl.ESL.COM>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 57


> I can't agree with this.  There are tradeoffs that can be made.  In
> particular, if you are willing to settle for doing without some of the
> fanciest functionality of any given window system, it is possible and
> productive to define a window-system independent layer on which to 
> build your software.
> 
> As proof of this claim, consider the Andrew software...

Yes you can address performance, but at the price of design and
maintenance, and even then there is a limit.  The more general the
backend of the interface the more complex the work that it does.  The
only way to eke that last drop of performance out of the box is to talk
straight to the hardware, but then you lose vendor-neutrality.  

If, on the other hand, performance is not a critical problem and you 
are willing, for all intents and purposes, to write and maintain your
own window system you can do wonders; look at X.  There is a DDI layer
which the server operates from, and generally that's just fine.  HP
(and other vendors with high end graphics hardware products) couldn't
just wedge their sophisticated functionality into the server/DDI, and so
special windows that are controlled by the special purpose hardware are
available.

I'll bet that your use of X is not much more sophisticated than as a
graphics and input library.  All of the other "windowing" work you do 
yourself.  You have to some degree (perhaps a large degree) written 
your own window system.

My comment about hoplessness had to do purely with business issues.
I assume that the management is concerned with engineering resources
being consumed as window system standards change.  I'm making the point
that those resources are either consumed during the change, or they are
consumed during the design, development, and maintenance of the
"interface layer."  The idea that there's a free lunch lurking in this 
"interface layer" approach to multiple-backend support is hopeless.

Please note that the idea of interface layers is not useless (I write
widgets which essentially provide and interface layer ;-).  If one has
decided upon a single backend (most people do only a single front end),
then an interface layer becomes a side effect of proper design -- it
becomes a level of abstraction within the design.

Ideally you have a single standard to build upon and your program
starts from there.  You then avoid the design and development
headaches, and you can pay someone else to do the maintenance.  I think
that's why the X Window System(tm) holds so much promise.  If it takes
over, we can dispense with that part (the interface layer) of our
design, development and maintenance, and go directly to providing the 
value added by our programs.

> -- Nathaniel S. Borenstein


----

Ben