[ale] Object Model Vision

[Brad Dixon]

Ok, here is a little junket I drafted to be a little bit more specific on
what I was talking about originally. This has been a very interesting
thread.

Object Models, User Interfaces, and Linux.
by Brad Dixon (gt5392c at prism.gatech.edu)

How many times have we seen inovative user interfaces fall by the way side
because of the operating system they were attached to? NeXT and NeXTSTEP,
Apple and the MacOS, IBM and the Workplace Shell (OS/2). Sometimes
innovation can fail even when it is worthy in nature. Currently there
appear to be three distinct flavors of user interface: the Microsoft
"Win95" model, Apple's MacOS, and the "Unix" feel. All three have their
adherants and millitant supporters. I personally am not fond of any of
them. In deference to the supporters of different user interfaces
everywhere, I will not criticize these platforms, but I will attempt to
show how we, the linux community, can do better.

I'm a reformed OS/2 user. Back in my DOS days I longed for an operating
system that would allow me to do more then one thing at a time. DOS and
Windows never filled that role, so I moved on to the only system that I
new of at the time that did: OS/2. The longer I was a OS/2 uer, however,
the more I realized that the pace of innovation at IBM was slowly grinding
to a halt. I moved on to linux, and have loved it. I do, however, miss
IBM's object oriented user interface, the "Workplace Shell" (WPS). I would
love to see some of the concepts in IBM's WPS explored in the linux/unix
enviroment, along with other advanced concepts such as network objects and
object file systems.

Another thing you should know about me: I'm not that good of a programmer.
These are ideas that I have that are looking for implementers. I've never
programmed under linux, and have never programmed much beyond what my work
and school has required. I am, however, a quick learner. So let us move
on...

I forsee three components to a usefull object system. The first would be
the object database a basic object classes. A root object would have
methods for saving and restoring itself from the object database, and
answering simple queries about its status. The object database would be
either a local or remote clearinghouse for objects. It would store
specific instances of objects (e.g. a data file named document) as well as
object classes (a tar file object, for instance). In a workgroup setting,
indiviudal requests for object instances whose classes were not stored on
the local machine could be fullfilled by the workgroup object server. I've
read that BeOS, the operating system for the Be computer, uses a database
for file and object storage. I've not investigated further then that,
however. (http://www.be.com)

The second component would be the meat and potatoes of the system.
Starting with simple classes of objects like datafile and folder, a object
hierarchy would be constructed that could be used by the programmer and
user alike. For instance, a user would use folder objects to look at and
manipulate folder objects. A programmer would use a folder object to
provide a drag and drop location in his program for objects that were
dragged from other folders or programs. For some more info on how
something might look, you might want to take a tounge-in-cheek look at the
IBM Common User Access (CUA) demo that I have made available at
http://r52h146.res.gatech.edu/~bdixon/ibmcua.zip. It is a DOS application.

The power of the object system comes into play when you begin to extend
object classes. For instance, a folder class could be extended to populate
the interior of the folder with the contents of a tar file. A different
programmer, in a different language, could also extend the same folder
class with a folder that would populate the interior with files from a
remote ftp site. Now a user could drag a ftp site off of the template
list, fill out the connection details, double click and see a file
listing. Drilling down through several layers of directories, they would
get to a tar file that they were interested in. Double clicking on the tar
file would produce another folder that contained all of the files from the
folder. They could then select a specific file from the tar file, and drag
it to their desktop or to a program.

Thirdly, I feel that any object system that runs in the linux/unix
enviroment needs to fully aknowledge the power and speed of the command
line. I feel that a usefull way of doing this would be to design a object
file system that could be mounted into the normal linux/unix file
hierarchy, for example, as the /home directory. Here users would see file
and textual representations of their objects. Using the above ftp and tar
file example, the user would be able to perform the same actions at the
command prompt using the common linux/unix tools cp, cd, and "|". Object
commands that would be accomplished through a popup menu could be
performed on the command line as well (e.g. "document --print" to print a
document using the classes print method or "tarfile --help" to get help on
a tar file object). I feel that any user interface has failed if it
constricts the user, and we should not be constricted to the mouse unless
we would like to be.

If your curiosity is stimulated by this, you should take a look at object
databases such as Texas and CORBA projects such as the Inter Language
Unification (ilu) program by Xerox Parc. You should also look at the OS/2
WPS and documents describing it's internal design and programming. I've
got some and I'll try to convert them to text in the future.

Brad

 -- 
Brad Dixon                                                                  
Georgia Tech Research Institute -- Atlanta, GA                             
bdixon at cmdl.gtri.gatech.edu