Bases [far34]

[Gary D. Duzan]

In Message <9305172238.AA23280@clipper.ens.fr> ,
   Francois-Rene Rideau <rideau@clipper.ens.fr> wrote:

=> 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).
=>
   Not necessarily, if drivers are implemented like normal objects.

=>SPECS
=>~~~~~
=>
=>agreements
=>~~~~~~~~~~
=>a) MOOSE is "OO" (see Unknown, a))

   Yeah, whatever that means.

=>b) we'll develop a generic UI (user interface), that will
=>specialize/extend into a TUI (Text UI) and a GUI (Graphical).

   Fair enough.

=>Unknown
=>~~~~~~~
=>
=>Questions:
=>@) What will we do that will be the same as or different from
=>other systems, currently existing or being developped ?

   I think it is fair to say that there will be no single feature
that won't have been implemented in some other system. The only
real innovation I think we can expect is in our particular
combination of features and overall system structure.

=>a) What does OO means for an OS ; i.e. what do we mean by "object" ?

   An object is a combination of state, code, and interface. Threads
execute the code, and there may be more that one thread executing on
one or more method. Objects are medium to large-sized from the system
level, though larger objects may manage smaller objects, which can
be addressed like the larger ones.

=>b) How light will our basic objects/threads/tasks/processes be ?

   As light as they can be without giving up inter-object
protection.

=>c) What kind of typing/checking will the kernel/base system include,
=>if any ?

   As I've said in the past, types are a mess. We might want to
attach type information with each call and have the called object
(or the kernel) check the information. We could limit passed
types to a set of standard types, building up more complex ones
from there, or maybe have a complex type server. This adds a lot
of additional overhead to building a message. Alternatively, we
could provide a system for callers to determine the type of
object method interfaces and rely on sanity checks in the
destination object. I would suggest the latter, since for the
most part data is data, and nonsense calls would generate
nonsense results, and sanity checks could handle most devistating
cases.

=>d) Must we include a standard LLL in the base system

   No. It might be a good idea on some systems, and there should
be nothing hindering its implementation, but high-level languages
should suffice for the most part. I don't believe the primary
target systems require LLL support.

=>e) Must we prepare for future distributedness (i.e. refuse solutions
=>that won't adapt to a distributed OS).

   Yes. The more flexibility the better.

=>FIRST IMPLEMENTATION
=>~~~~~~~~~~~~~~~~~~~~
=>agreements
=>~~~~~~~~~
=>a) Moose will run on 386 PC compatible machines.
=>
   The 386 version, yeah. :-) I'm thinking that I may get a
SPARC Classic or something and build my code there. The further
I can get from DOS machines, the better.

=>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.

   Whatever we can't implement in objects.

=>b) Object ID's.

   A large binary number, possibly arranged to allow addressing
smaller objects within system objects.

=>c) Objects Classes.

   I prefer the Ellie-object model of grouping objects by interface
rather than by inheritance classes. An object's class is its
interface.

=>Solutions proposed:
=>Fare:
=>a) a 386 with extended memory (even 384KB suffice for just booting
=>with a console ?).

   We should focus on making it small, but I don't think it
makes much sense trying to predict the size of the final product
before it is started.

=>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).

   Non-portable. The 386 implementation may map object ids to
segment, though.

=>c)  [ ... stuff about object disk images ... ]

   Object code is straightforward enough. I've not been completely
sold on the idea of persistant object state, but it is a good
possibility.  If inter-object references aren't tied to hardware
addresses, restoring them would be easier, assuming the kernel can
rebuild its list of objects.

=>Please state your mind.

   You really don't want to know what is in there. :-)

=>Please recall forgotten points.

   There are plenty of things I would rather forget. :-)

=>Please add your comments.

   _The Simpsons_ is a cool show. :-)

=>Please correct mistype/broken english, or mistakes.

   All English is broken. :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                         Humble Practitioner of the Computer Arts