Re: Exo-graphical systems (Was: [elysium-developers] PCT])

[Claus M. <cla...@ma...>]

Her er et udkast til en tekst om exografiske interfaces til hjemmesiden.
Kommentarer er velkomne.


Thoughts on exo-interface systems


The basic philosophy behind exokernels, which has been discussed elsewhere
on this site are here applied to user interface systems. This actually means
that we have to apply the two most important features of exo-kernels:



a)     Application of as few and as general abstractions as possible

b)     Possibility for direct access to underlying systems (the hardware in
the kernel case)



Let us try to imagine the OS from the point of view of a user - specifically
an architect. Now, the architect has to make a presentation of a project he
is working on. Typically some of the material needed has been made and some
has yet to be made. He has not used the computer earlier in the process, so
let us assume he has made some models and sketches. He has to import photos
of the models, he has to import scans of his sketches, he has to make some
technical drawings CAD-style, he has to make a 3d-representation of his
project and render those to 2d-images and he has to assemble all this is on
a piece of paper - typically A1 or A0 (in Europe, at least). If he made this
in Windows (or Linux/X, System X, BeOS, etc.) he would conceptually start an
application (possibly CorelDraw or Adobe Illustrator) and start lay outing
the project. He would soon find out that Adobe Illustrator is prohibitively
difficult to write text in, so he would start Word up, write the text,
import it in Illustrator and set it up. Pictures would be scanned and
prepared in Adobe PhotoShop, AutoCAD would probably deliver the technical
drawings, 3dStudioMax would deliver the 3d-representation, etc. All of these
steps would require knowledge of file types and conversion between them,
loss of data and/or accuracy, repetitive actions and sometimes even direct
errors. All this, because the programs involved does not know each other's
abstractions.

It might seem strange to make a system designed for avoiding abstractions
deliver just such abstractions. The key thing to remember is, that
exo-systems are not about not making abstractions; it is about making as few
and as general ones as possible. This fits our scheme very well, because for
instance the page concept used by Word is very insufficient for a program
working like CorelDraw.

Another thing to take into account when designing interface systems is the
common user - for instance our architect. The architect does not really care
about programs at all. What does he need? He needs an abstraction for
images, one for sheets of paper, one of texts, one for virtual 3d-spaces in
which he can create the shapes he needs, he needs an abstraction for
technical 2d-representations of this 3d-space, ideally created without him
lifting a finger directly from the 3d-space representation. He does not need
an abstraction for programs, ports or icons. These concepts are (useful)
concepts from the view of the programmer; were he has almost always failed
is in recognizing that this representation is inadequate for a common user.

Exo-systems' have one prominent feature - they result in the creation of
several servers that supply abstractions. The kernel makes an abstract
representation of simple kernel functions, such as address spaces. The
Elysium OS will probably sport a graphics server, making screens available
as representation. If we expand this concept we may have a sheet server.
When asking the server for something, you ask it for a sheet of paper. You
are now the only process with access to this particular sheet. You might
then supply your own abstractions: A sheet might contain frames like a
screen contains view, for instance. All programs matching your frame
specification will be able to cooperate with your process on this concept.
Both Word, PageMaker and CorelDraw would be able to do something useful with
this format. An image is likewise created when asking for an image from the
image server, a 3d space from the VR server and so forth. This would make
implementing ToolGlasses or Markup Menus very easy, since they are just
servers providing proper abstractions for overlay operations on objects from
other servers.

What about the inter-program cooperation? It is obvious that it should still
be possible to make a program CorelDraw-style that works completely on
itself (since exo systems, may we never forget it, should not enforce but
offer abstractions), but it would be interesting to create programs that
work entirely on server objects. This is of course the primary area of
research currently since the abstractions we need to provide must never be
more constraining than least possible. The abstractions must also be strong,
easy to use and worthwhile. The primary server that we need to provide is a
Graphics Server, a Window Server, a Pointing Device Server and a Block
Device Server. Work on these are progressing (this document being one sign
of progress), and later the need for a ToolGlass server and a Sheet Server
will become significant.



xmentor, 21/02 2000