[unios] Generic design. More comments

[Pieter Dumon]

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

Some comments and questions,

Pieter

>'Generic design' model
>======================
>
>The base is an object-oriented system. With object-oriented I don't mean
>that the OS has to be written in a OO language, but that the things that
>the OS is concerned with are generalized to be different kinds of the
>same
>concept, objects. Everything in the system is an object. Also many
>objects
>that are usually implemented as compile-time objects or external files
>should be made as system objects, giving other objects, including
>authorized users, the ability to modify it's value independent of the
>application itself.

That's what Mach and WindowsNT do, but what do you actually mean by
"independent of the application itself"?

>Interfaces
>----------
>An interface is as the methods in classes, but only the public ones.
>Private methods are not interesting for the OS. All objects conform to
>defined interfaces, depending on the nature of the particular object. All
>access to an object is done via these interfaces. What an object type can
>do is defined by what interfaces it supports.
>Interfaces are declared to the system, and they never change. If new
>features are introduced, they have to be added in an add-on interface.

Does this mean that e.g. a Word7 and a Word97- document would have a
different set of methods? Isn't it simpler to use the extended interface
for all previous versions ? (Off course, things must be kept compatible.
Old features must still be supported.)  

>Object characteristics
>----------------------
>Objects indeed differ from traditional compile-time objects. They don't
>support inheritance. Variables are not modifiable directly, and not even
>visible to the world. Changes have to be made throu calls to the
>interfaces.
>Actually, the only definition of an object is that it is registered with
>the OS and conform to the object rules.

If you would register _all_ object types... This will be like the WinNT
registry but then even more huge. It's indeed useful, however.

>Object handlers
>---------------
>Something that corresponds to the actual code that performs the methods
>of
>traditional objects is needed. I call the constructions that does this
>'object handlers', OHs. These are the very things that brings the system
>to
>life. Whenever an object need to do something, it's the OH of that object
>type that does it. What the objects really are, is up to the OHs. The
>objects themselves does *not* contain any data, except for maybe some
>small
>attributes that all objects have. Otherwise data is all handled by the
>OHs.
>Object types are not statically bounded to a specific OH. They can be
>"reassociated" with another OH, just as file extensions are associated
>with a program.

This is rather confusing. Where is the data kept, then if it is not in the
objects? Or are your objects just "components" (with some general
attributes and for the rest code methods)? I think you should use the
words "object types" and "objects" more precisely. "Objects" (I mean data)
should be able to be handled by multiple OH's, even at the same time, not 
needing to switch any association.


>Object security and interaction
>-------------------------------
>If a object wants to gain access to another object that it does not
>already have access to, no matter what object or purpose, it asks the OS.
>If the security policy permits access, a dependancy is registered; both
>that the client uses the object and that the (server) object is used by
>the client. The client gets access to a handle to the object. Without a
>handle (which BTW can't be traded without interference of the system),
>access is not possible.
>Access may be given to different degrees. Say that an object supports two
>interfaces; the 'read raw data' and the 'write raw data' interfaces...
>then access could be restricted to just the 'read' interface, and it
>might even be invisible to the client object that it's possible to write
>to the target at all.

You will need to implement each object as a seperate thread, like this.
Then you can control the access through control of the IPC. This would
however take much of the cpu power... E.g. an object wants to read from a
file. So, it calls the OHs of that object. If you want to control the
ability of the first object calling the OH's of the file object, you must
implement each of the 2 objects as a seperate process. This means lots of
overhead... It's easier to just implement a file system process
(object) wich other can call to open and read/write files. This can off
ocurse be implemented in your system , but it doesn't fit in it,it's not
like the spirit of your system. The code to talk to the file server is
then implemented as a shared library. This is just a conventional system.
  
>Objects (which include most resources) can be shared in some different
>ways, all very fundamental. This can then be applied to files and other
>resources. The same data or code should never have to be loaded twice
>when
>used simultanously by different processes.

Off course!!! Every existing OS since the sixties does this. (except for
DOS).

>An important detail in the resource sharing is that objects can be
>notified when a resource they are using is modified. This is good for a
>great many purposes. For example, a process is notified when its
>configuration is changed, an application is notified when the size of its
>window is changed, an email program is notified when a connection is made
>to the internet, an object is notified when a file it opened in shared
>mode is changed, etc, etc.

This is a good idea, and is indeed already used in all normal systems.
However, in your implementation, this would mean the window an application
uses and the application itself have to be implemented as seperate
threads. Well, that would be achievable, but if you are even going to put
the application and its configuration in seperate threads...

>System tree
>-----------
>The whole system is made into a single directory structure, where every
>object is an own node.
>The system tree is very flexible. The OS only keeps track of the system
>tree's structure and dependencies. Processes are run by special objects
>that implement multitasking. A node can implement its subtree in its own
>way, depending on the type of the node. In this way a FS can provide the
>whole disk contents as a subtree. Users are mounted on arbitrary (but
>well-defined) places in the system tree, and have full control over
>everything that branches out from his 'home location' and their children.
>This can be customized. The users home directory becomes his root dir,
>and he cannot 'travel' outside it, unless he is given access to outside
>objects. If he is, he can also travel to the granted objects.
>Maybe I should point out specificly that secondary storage is a part of
>the tree too. Objects that are on disk - most resembling files - look and
>act the same as objects in RAM, except for the storage method. It isn't
>important if an object is stored in RAM, on disk, on a network - or all
>three. Almost forgot, every object instance has a human-readable name, so
>you can browse the whole system tree and actually understand what
>everything is. You can even configure the system with no more help than
>this tree browser/editor.

This is a very good system for normal users. They don't need to know about 
the details of where and how an object (e.g. a music file or a game) is
stored. But for programmers and powerusers....

>OID servers
>-----------
>OID servers are a corner-stone in the system. They keep track of what
>objects there are, their object id (hence the name), and all dependences
>regarding the objects, including parent and children (= its place in the
>system tree). They have the responsibility to store these data on their
>own.
>There most probably are several OID server on a system. The first one
>contains the system tree's root and close objects such as other OID
>servers. Each partition - or at least each physical storage unit - should
>have an own OID server which controls everything on that unit.
>An OID server is also implemented by each network interface, to redirect
>object references on the network. These can perform table lookup on OIDs,
>to translate them into the correct OIDs on remote system. (OIDs are
>system-wide, but not network-wide. This is only for normal use, however.
>In
>distributed systems, OIDs could well be network-wide.)
>The only thing that OIDs does is to identify each object, but the system
>OID server will use the first part of it to know what other OID server to
>call.
>It's up to the server to create new OIDs. How they are constructed is
>only
>dealt with by the responsible server.

This storage system is very good and useful and flexible. Like this you
can represent the users on another PC just like objects. 
Ok, but I don't like the idea of the OH's and objects like you pointed it
out here.

>Negative side-effects
>---------------------
>- The space needed increases somewhat.

Somewhat ?? A lot, you mean. But that's no problem. If you add the
flexibility...

>- The speed degradation could become a problem when many objects that
>uses the same resource need to be notified of a change at the same time.
>It should be possible to reduce such effects.

As I pointed out, it will be your securing system that takes up _lots_ of
cpu time.

>- The number of objects could maybe become overwhelming. The same problem
>could arise with OHs too, and maybe even with interfaces.

If the organisation is good...

>- Programmers may be displeased with the common objects' design. Compare
>with the different user interface styles used in different code
>libraries.
>(This specific problem should not arise when using these ideas, it's just
>an example.)

Ah, that's a very big fact, and I'm a programmer too... Your design of
OH's would become unoverviewable in a short time, and it is not generic at
all and not flexible at all. That's why I don't like it.


>- It's an unconventional solution. Developers and users might find it
>difficult to migrate to the new OS.

I don't think "normal" users (home users and 90% of the office users)
would have problems. If you make the representation simple enough...
For developpers, it's easy to migrate. They understand the system (or
should understand), but if they are going to migrate is the question...

>Positive side-effects
>---------------------
>- No separate mechanism for file access/sharing is needed.

Hm, do te current OSs need seperate mechanisms? File sharing is just
hidden form the users. 

>- All flexibility that could possibly be wanted is achieved at no extra
>effort.

if you want to take the effort of learning all different OH's, that is...

>- No external and possibly bulky security mechanism is needed, and very
>detailed security policies can be applied.

The securitty will be bulky whatsoever, in this system.

>- The construction with different interfaces and OHs is very powerful,
>allowing for an OO access method, where different implementations and
>intermediate layers can be used transparently. I could give an infinite
>number of examples, so I'll avoid giving any at all, so I don't make the
>possibilities look limited. :)

I don't thinks so...

>- Developers don't need to do as much peripheral work, since much of what
>they otherwise would have to do themselves is implemented system-wide as
>objects. A problem today is that programmers have to implement the same
>features over and over again.

Is this true? I don't think so. If you find the right source code, shared
libraries etc...

- Small, generic units can be combined to accompish more advanced tasks.
This is practised to some degree in UNIX, but much greater possibilities
arise in this system.

To _some_ degree ? 


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

------------------------------------------------------------------------
Help support ONElist, while generating interest in your product or
service. ONElist has a variety of advertising packages. Visit
http://www.onelist.com/advert.html for more information.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios