Bases [far34]

[Francois-Rene Rideau]

 Well, here is I think the main points we MUST agree before we can
begin coding what we call MOOSE (but we already can begin coding
IO drivers and suches).

SPECS
~~~~~

agreements
~~~~~~~~~~
a) MOOSE is "OO" (see Unknown, a))
b) we'll develop a generic UI (user interface), that will
specialize/extend into a TUI (Text UI) and a GUI (Graphical).
c)

Unknown
~~~~~~~

Questions:
@) What will we do that will be the same as or different from
other systems, currently existing or being developped ?
a) What does OO means for an OS ; i.e. what do we mean by "object" ?
b) How light will our basic objects/threads/tasks/processes be ?
c) What kind of typing/checking will the kernel/base system include,
if any ?
d) Must we include a standard LLL in the base system
e) Must we prepare for future distributedness (i.e. refuse solutions
that won't adapt to a distributed OS).

Answers:
Fare:
@) Object Orientedness will make us differ from everything else.
See a). Difference with NeXTStep ? I recommend using a tiny object
grain, whereas NeXTStep seems to use big objects and big messages.
a) it means objects are the generic basic system unit. Unix had files,
directories, devices, pipes, sockets, each completely different and
unextensible without kernel change. We'll have only one basic item,
which will be generic enough to contain code and data of any kind
wanted, and standard enough to be a media for code&data exchange
between programs (which is currently what @%^@%! computer users and
programmers most of the time).
b) Very light: objects are any kind, any size. A larger object is
a structure of smaller objects.
c) The whole thing. Typing some generalization of protection. At a
high level, typing IS protection. If you do not enforce typing
somehow, you won't have a secure OO system, so no one wishing
security will use system objects; you won't have an OO system, but
a common system like any other one; if so, let's just be happy with
unix.
Let us have a standard for describing objects. After that, we
can use this standard to describe other ways to describe objects, when
we want more extended classes. Let us have a HLL which will enable
direct access to this standard.
d) Yes, together with typing (will thus include code&data); see a);
at least, we need some way of exchanging code together with data.
Imagine a brand new format for this or that (example: the brand new
format YOU just designed); you'd like not to get/wait for/pay for
a brand huge (the hugest, the slowest/most difficult/most expensive
to get new version of each of your application to understand it; but
if you just get the proper small code for it, that's ok, and all your
apps will understand it). What I ask for is possible exchange of code,
in some compact and directly executable (or quickly compilable)
format.
e) Yes, because future machines WILL be distributed; the laws of
physics limit the power of a single processor. To break this barrier,
systems will HAVE to be distributed. So if we want not to write
Moose for nothing, we must prepare it for further extensions.


FIRST IMPLEMENTATION
~~~~~~~~~~~~~~~~~~~~
agreements
~~~~~~~~~
a) Moose will run on 386 PC compatible machines.

Unknown
~~~~~~~

Questions:


a) Kernel Requirements:
 - That's just a policy question, and there is a priori no rational
 arguments about it, but what machines we work on.
b) Object ID's.
c) Objects Classes.

Solutions proposed:
Fare:
a) a 386 with extended memory (even 384KB suffice for just booting
with a console ?).
b) use DT:Seg identifiers, or DT:Seg:Offset when needed. (when needed,
the offset may be considered as an argument to DT:Seg as a function
represented by the array of its values).
c) Disk representation will use integer codes (0,1,2,3,...) for
objects. When loaded to memory, these codes are eventually converted
to nearer or farer object IDs (and conversely), for fast
evaluation/access. (Note: this can be done at load time, or at use
time, or sometime in between, what is important is that disk
representation is portable, whereas memory representation is
efficient). 
To physically access an object, we need both its local data and its
more global class, and perhaps even more global meta-classes (a/o
classes you inherit from, etc). So what I propose is, at link time
(which can be just after loading, or during use), use two pointers
(or standard IDs of any kind), one to the class as a description of
data/methods, and to the effective data. If someone wants virtual
pointers, he'll have to use virtual memory traps so that a common
pointer using program can access it.


Please state your mind.
Please recall forgotten points.
Please add your comments.
Please correct mistype/broken english, or mistakes.
I'll maintain this bases list until we come to an agreement, or
someone is willing to replace me, so even a quick personal reply
in telegraphic style will be accepted, and I'll summarize it as soon
as received.

   ,
Fare