ReMaP -- Resource Manager Project
The Project Proposal
0. Prologue
-----------
With the advent of graphical-based user interfaces (GUI), almost each
computer niche created it's own way of handling the user interface.
For personal computers, one of the first system to appear was the
Macintosh's. Most of its concepts were result of pioneer work at Xerox.
This system is considered the paradigm of user interfaces. The 'resource'
idea used in the Mac will serve as main inspiration for this project.
Another breakthrough in GUI was the X-windows system. This system was
developed in MIT and is extremely flexible. X-windows is one of the few
(if not the only one) to provide full-transparency over network. If the
client (main application) and the server (low-level GUI handler) are
running on the same machine, this is purely coincidental. Interfaces can
be spread over different machines, from different architectures and even
from different operating systems. This client-server paradigm will also be
used is this project.
The Amiga GUI system is quite lighter in complexity than the two previously
mentioned, although it is consensual that is fast, flexible, intuitive and
has (hardware based) features (like screens) that allow small systems to
have a high-performance graphical interface. At last, Microsoft Windows
bring about almost nothing new in GUI (just old Mac ideas) balanced with a
heavy-weight marketing operation. This feature associated with the
low-price and very abundant PC's, allowed Windows to obtain virtually the
monopoly of the computer market.
However there are some resistant survivors (like me) to this mainstream.
What is the problem with Amiga ? Quite simple : it has just stopped.
There are two major releases of the Amiga OS : 1.3 and 2.0. The Release
3.0 is almost just a refinement of 2.0, with very little new. Comparing
the advance of the Amiga GUI with Windows, there is an enormous difference.
In addition to this fact, the Mac technology uses resources from a long
time, while there is nothing (to my knowledge) done in that area in the
Amiga. NOTE: Do not make confusion between the 'resource's I'm talking
about with the low-level resources on Amiga, used for low-level hardware
arbitration.
1. Objectives
---------------
The Resource Manager Project (ReMaP for short) has the purpose
to implement high-level software layer over an existing GUI system
(MUI, BOOPSI or even plain intuition). The main objectives of this
project are :
a) To reduce the development effort on GUI to the minimum. A couple of
lines would be enough to trigger an arbitrary complex interface.
b) To make user interfaces as robust as possible. With X-windows, you can
just 'kill' a process, and the whole interface vanishes. No hang-up
windows, no dead memory, just simple and clean.
c) To allow the interface to be spread over a network. The client-server
paradigm is desired here. No pointer, no shared memory, again simple and
clean.
I think that the implementation of these three ideas could both offer
robustness to the user and flexibility to the developer. I propose the
creation of a group of Amiga developers and enthusiasts to achieve the
mentioned goals by implementing it in a freeware basis software.
Finally I'd like to stress that the most appropriated approach would the
object oriented one and that the base system should be as language
independent as possible. (Base system means ReMaP plus the lower layers
until the hardware).
1.1. The developer's viewpoint
------------------------------
The main idea is to turn the building of user interfaces as easy as
possible. To achieve this goal I propose that the interface creation and
function should be as automatic as possible. The great majority of
programs _use_ a GUI as a tool, not as an objective. This concept
justifies that the internal working of the GUI should not be of the concern
of the developer. It doesn't make much sense to spend hours building and
fine-tuning an interface (in that usual, tedious and slow loop:
edit-compile-run) if there are ways of performing this job aside from
compilation/linkage issues.
To achieve this goal I propose the use of the 'resource' paradigm. A (very
simple) language must be designed in order to be interpreted in real-time,
building this way the whole interface. Obviously, the more high-level this
language is, more slower the system will be. There could be a set of
language levels, where a developer can step to lower ones by the use of
mini-compilers or cpp-like programs. This way the interface structure and
the object's parameters are embedded in these 'scripts'. Note that this
feature is totally language independent. I think that this is the first
time that I refer to 'objects'. In order to have flexibility and data
abstraction, it seems to me that every interface element should be
abstracted as an object.
This approach virtually eliminates all concerns that a developer could have
concerning data structures (or objects) related with interface. The
application itself must have the most abstract view of the interface.
1.2. The user's viewpoint
-------------------------
The kind of abstraction involved here that was outlined in the previous
section allows the system to be quite robust. All that coding involving
error-checking and handling of the unexpected can be moved from the
application to the base system. When a user wants to kill an application,
the system must assure that (at least) the interface vanishes, just like
xkill (from X-windows). With this approach, the system has total control
over the details of the interface allowing it to delete the interface as
easily as it was created. There is nothing more frustrating than a buggy
interface. The end user should have bug free interface. Let the bugs stay
with the main application. Anytime the core code of an application
crashes, the system should be robust enough to free the user from a 'dead
interface'.
1.3. The system's viewpoint
---------------------------
It was said before that ReMaP should use client-server paradigm. This
architecture insulates the client from the server in terms of 'dangerous'
things like pointers, shared memory, etc. The cost to pay is a loss in
speed. However I believe that high level of communication between the
client and the server, lightens the communication overhead. The benefits
justify the approach.
The server is just a program running in an arbitrary machine. Unlike
X-windows, the appearance of the interface will be dependent of the way the
server is related to the rest of the underneath system. Since the server's
connection to the client is pipe-like, all memory management is up to the
server, avoiding this way memory allocation problems and increasing the
robustness of the system.
All application desiring to use ReMaP must establish a connection (either
local or remote, over a network) with a server. The resources handling
(script interpretation) are handled by the client. The client has
references (ID integers) to every object allocated by the client. The
server has knowledge of which object were allocated by each client. (The
word 'allocated' is used in a broad meaning, like NewObject(),
OpenWindow(), AllocMem(), etc.). This way, it is possible to flush a whole
interface tree without fearing for dead memory accesses (mungwall hits).
2. Project organization
-----------------------
I'd like to contact everyone interested in working or contributing to this
project. I'd like to discuss extensively the points outlined above. I
think that the project must be designed top-bottom, starting with way
resources are specified, followed by the server, continuing to the server
design and ending with server's contact to the underneath system. Many
parts of the project may be implemented in parallel.
I'll try to create a mailing list for the exclusive use of the project, in
order to maintain a close contact with everyone involved in the project.
Finally I'd like to stress that this project seems quite new in Amiga
development area. I have no knowledge of a similar project to the moment
of this writing.
I hope that this project contributes anyway to the development of Amiga
software technology. Even in these troublesome days of Amiga history, I
still hope that Amiga will have a relevant role in computer scene.
A. History
----------
Start date ...... 29 Nov 1995
Revision date ... 7 Dec 1995
B. Author's contact
-------------------
Address: Rodrigo Ventura
Rua Jose Leilote, 26
1900 Lisboa
Portugal
Tel: 035-01-8681965
(WARN: English is not my native language)
Email: l36612@alfa.ist.utl.pt
WWW: http://alfa.ist.utl.pt/~l36612