🚀 go-pugleaf

                  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 Jos=E9 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


    +--------------------------------------------------------+-----------+
    |         Rodrigo Ventura, alias <Master Yoda>           |     /     |
    +--------------------------------------------------------+  - / ---  |
    |  Electronic Engineering Course, Control and Robotics   |  | |  |   |
    |     Instituto Superior T=E9cnico, Lisboa, Portugal       |  | |  |   =
    +--------------------------------------------------------+  - /  |   |
    | L36612@alfa.ist.utl.pt, http://alfa.ist.utl.pt/~l36612 |   /       |
    +--------------------------------------------------------+-----------+

--
MAIL comp.sys.amiga.announce announcements to announce@cs.ucdavis.edu.
Mailing list: announce-request@cs.ucdavis.edu; Moderator: zerkle@cs.ucdavis.edu
Servers: http://seclab.cs.ucdavis.edu/~zerkle/announce, announce@cs.ucdavis.edu