🚀 go-pugleaf

Bert Driehuis (driehuis@ooc.uva.nl) asks if the low-level graphics layers of
IV have been re-written on other systems, thus facilitating an easier port. I
have seen some comments about this come by before and I think that someone
is porting to PM. I assume that those parties will answer Bert's question.

I think that there is a broader issue concerning portability. It seems that a
great deal of attention was given to isolating, and in effect abstracting, the
low-level display control in the IV library. This helps in porting to other
window systems. But how well has the file system been isolated? IV seems to be
quite dependent on UNIX. Porting to Windows, MacOS, OS/2 (ugh), or even VMS, is
not only a port to another window system, but in fact is a port to another
SYSTEM altogether (I have not studied version 3.0, so please ignore this 
message if this has already been taken care of.)

Other questions arise: what other assumptions are made by the IV library about
the system it's on? What other dependencies can be "abstracted out" so that
porting to ANYTHING becomes easier and more feasible? Is there a way to
automatically handle one vs. two vs. three button mouses with some sort of low
level mapping? Or do applications have to worry about that? Are there reasons
to abstract the keyboard?

The idea here is to isolate those portions of the IV library that are 
dependant on a specific platform. Abstractions (a la abstract base classes or
global functions) can then be defined for these low-level services and then
implemented for a variety of platforms. The three abstractions that seem
immediately obvious are the display interaction, the file system, and the mouse
(part of the display abstraction?). A real question to think about is "what are
the assumptions we make about the platform that make it hard to port the 
library"?

Perhaps version 4.0 ... :-)

Thank you for your time.

Steven Fogel
fogel@uswest.com
consulting at U S WEST Advanced Technologies
(303) 541-6296