[unios] Re: Generic design. More comments

Pieter Dumon Pieter.Dumon@rug.ac.be
Wed, 16 Dec 1998 14:15:48 +0100 (MET)


From: Pieter Dumon <Pieter.Dumon@rug.ac.be>

> 
> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
> 
> Let me take an example of how OH's would work:
> When a function in an interface of an object is called by another object
> that has been granted access, the following happens. The OH that implements
> the interface for the type of objects that the current one belongs to is
> called, with the caller's parameters and the OID of the called object. The
> OH does whatever needs to be done, like fetching the objects data from its
> own (the OH's) storage, and then returns the result to the caller...
> For the caller it looks like he talks to the object, when he in fact talks
> to an OH.
> If the object can - logically - be represented in several ways (like text,
> that can be shown as formatted or pure text), the OH can say that the
> object supports both interfaces. Both interfaces point to the same OH, but
> different entry points of course. If now only the OH implements stripping
> of formatting tags, clients can access the text, even if they do not
> support formatted text.
> 
> An Object Handler is an object too... all OH's share one interface, with
> commands (mainly for use by the system) that has to do with its function.
> 
> Access to an object is considered for every supported interface. Compare
> this to the rather unflexible read/write/execute access types on UNIX.

OK, much clearer now. Sounds good.  It is indeed very flexible and
powerful. The only thing that might degrade is performance...
Now, how can we implement the low-level part of the OS to support this?
There are some options:
First some definitions:
  low-level : kernel, hardware interface
  mid-level : user management,security, file system etc
  high-level: OS system programs, UI etc

 - A completely independent low-level part wich can run this system, 
   and Win32,POSIX,OS/2,DOS etc, as seperate subsystems:

   pro : - very fast
         - stable : if one subsystem has problems, the others don't
                    depend.
         - flexible
         - independent low-level (not dedicted to one function)
   con : - not just one mid-level part of the OS 

- A complete independent low-level part wich runs your systems, and
  your system can off course run POSIX,Win32,OS/2,DOS etc on top of it,
  together with its own API (Like NT)
  
  pro : - one mid-level part, your system, which runs the other mid-level
          parts
        - still very flexible
  con : - not as fast
        - other subsystems depend on the basic subsystem
     

- A low-level that allready implements the basic parts of your system,
  so the low-level are objetcs too.
  
  pro : - fast
  con : - larger and less stable low-level
        - all mid-levels depend on the implementation of the basic
          "mid"-level system in the low level.
        - harder to develop low-level
        - low-level dedicated to your system.

One more thing : you should think about a good name for your system.


Pieter

----------------------------------------
 Pieter.Dumon@rug.ac.be               
                                      
 http://studwww.rug.ac.be/~pdumon     
 
 ICQ  : 12428974
---------------------------------------

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios