This text is just a short list of things that have to be done in the
object oriented e project. As of this writing the ooep is only at the
beginning, so a lot of things have to be done.


1. General


creation of basic objects: stream. This object is needed for files,
devices and a lot more objects.

The stream object represents any kind of data stream. Basically there are
two streams: input and output. Input from file or keyboard is an example
for input stream, output to the screen or to files for output stream.

The opposite of stream is a record based handling of e.g. files.


documentation of the modules. *I* know how to use them since I wrote
most of them. Trey may recognize what I have done but someone else may
not. Up to now I don't know what you think of the objects, please tell
me.

As you may see when you take a look at the sources I chose the autodoc way
of documenting things. Though the autodocs are nice when you want to know
what a single function does it has one great disadvantage: it doesn't show
which procs work with each other. There have to be guides to show this.


implement other objects as listed in The Plan. The Plan can be found in
emodules:oomodules/oodco/OOEProject.

Increase communication :)  The list has almost no traffic at all, let's
change this. If is keeps to be so quiet I'll prepare the package to post it
to aminet.

Notify the e mailing list. When we're working and both lists are running
we should try to involve more people.


2. Objects

2.1 General

Modify the resource tracking system to work with the Explorer. Only the
Resource Master needs some simple modifications.


2.2 Application object

This object basically does what MUI does. It builds a commodity with an arexx
port and opens the application catalog(s) and libraries. An optional GUI is
created and handled.

The commodity creation uses the commodity object (if it exists). The GUI
is a list for MUI, BGUI, EasyGUI or a pointer to a proc provided by the
programmer. This is also the case for opening/closing/handling the gui.


2.3 Database objects

- Support external record headers

  Build datafile of names of files that contain record headers. The record
  headers look like those in standard data files and can be parsed by the
  same methods.


2.4 Reference object

When the reference object is used a global instance is needed. It should be
initialized by the application object.



Exceptions
----------

Work out and implement an exeption scheme.

Libraries: Raise "LIB",text on failure
Devices:   Raise "dev", ""
GUI:
  guis - screens
  guiw - windows
  guif - fonts
  guir - requesters


Exception handling:

The application should display a message that tells the user what went wrong.
This can be done using requesters and/or status lines. The proc that
handles the display could be implemented in the application.m or in an extra
exception.m. Exception.m could have a compiler switch to minimize the code,
e.g. simple text messages for a small shell-based program and requesters for
gui-based applications.

After displaying the application should

a) use a work-around to solve the problem, e.g. use a smaller font if the gui
couldn't be opened with the large font.

b) continue its work at the position before the function was called that
caused the exception with the old status - no data should be lost.

Gui-based apps should have an exception handler at their handle-idcmp()
proc to catch any Rethrow()'ed exceptions. It would exit nicely to the next
Wait(). That would be the case for the application object to create (see the
corresponding chapter for the application object).

