[unios] Re: Generic design. More comments

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

At 16:59 1998-12-11 , you wrote:
>From: Pieter Dumon <Pieter.Dumon@rug.ac.be>
>
>>'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"?

The point is that settings that are of public interest are made into
objects. Authorized objects can view and change them. It's much like
configuration files...
 When changed, the parent app is notified.
These objects can be either declared to be objects of general types... like
text strings or integers, or they could be taken care of by the application
itself, allowing for more detailed control. Whatever the preferred way, it
will look the same to others, since they use the same interfaces.

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

Upgrades that change the API's are really troublesome...
Either new functions could be added in a new interface, or they could
extend the old interface.  The important thing is just that clients that
were expecting the old version will still work with the new one.

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

Registering the OH's and interfaces would mostly be for internal and speed
purposes, I guess. Object types would maybe not even have to be registered
at all... I dunno, needs to be investigated.
With the actual objects (that I were talking about), they need to be
registered (with an OID server) to simply acquire object characteristics
like ability to be used and shared.
This would somewhat resemble the Windows' registry... at the same time it
would resemble the UNIX tree, since files and networked resources are
represented too.
Something that it might not share with other models is that it includes the
whole system... from hardware representations and user mounting points to
processes and graphics windows. They're all just the same... objects in a
tree.

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

Sorry if I've not expressed myself clear... Here's some somewhat formal
definitions:
Object: The abstract thing that is registered with an OID server as an
object. Its place in the system tree, length of life and security measures
are taken care of by others.
Object Handler: Implements the interface and inner functions of objects of
a certail type (possibly several types).
Interface: A well-defined API that OH's can claim that an object supports.
Object type: All objects that are of the same type.

Objects handled by different OH's at the same time... this could be
troublesome, since maybe only one OH know exactly what an object is...
rather add filters, that can combine earlier functions into other and more
complex ones... This would work regardless of what object is in the bottom.

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

Every object does not, strictly, have to be a separate thread, since
they're just a hollow shell. Every OH should be an own thread, yes, and
maybe threaded for different objects too.
I don't think my way would be so slow... When a object gets access to
another, the allowed interfaces are, in some way, imported to the caller,
so all IPC can be done without other interference. But yes, one
inter-process call (+ return) would be needed.
Do modern systems really allow direct access to the FS? This seems to me as
a security problem.

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

You're right, it wouldn't fit in. The whole system consists of only objects
- all behaving the same way. Files would be the same, and not treated
differently by processes than RAM objects. When objects are being used,
they can be brought into RAM for performance reasons, but they logically
still exist on disk (local or networked).

To improve performance, maybe objects could be allowed to write directly
into clients memory area... that should be technically possible, don't you
think?

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

Umm... yes. The reason I explicitly stated it was that sharing is extended
to all objects. And I was thinking of more ways of sharing than I know any
other OS features.

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

I know that some things of what I mentioned are already implemented, like
notification on window resizing. Others I have not heard of, like if two
processes share the same file, the other one is notified when one makes
changes to the file, or a notification on network connection. Do other OSes
feature that?
And (of course) I was speaking about all objects, not just files. (Nothing
is just for files, generic design...)

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

Where an object is stored has to be perfectly clear. Its place is logically
in the system tree, but we also have to deal with where it's stored
physically. I guess... since everything on a drive is logically a sub-tree
of the drive's object representation, we know where the object is stored.
Remember the the system tree is the *only* directory structure needed. No
FS need to have an induvidual tree. As for non-native FS'es, there should
be no problem in having the files simulated as objects.
As to _what_ is dealt with, the OH's know this and the information is
readily availible.

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

Thanks! :)

>Ok, but I don't like the idea of the OH's and objects like you pointed it
>out here.

Just mention what you don't like (more than you've already said), and we'll
see what can be done about it. We *are* after all here to discuss.

>>Negative side-effects
>>---------------------
>>- The space needed increases somewhat.
>
>Somewhat ?? A lot, you mean. But that's no problem. If you add the
>flexibility...

I'd say that the additional flexibility and stability (never delete
anything that's used by even the most tiny of apps), plus some other
advantages, makes up for the additional space. And... IMO space can be
traded for other benefits in a higher degree as storage devices gets bigger
and cheaper.

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

I maybe need to clarify... security checks are only done when granting the
initial declarance of dependancy. After that, the objects communicate
directly to each other.
What I meant was that a object might be altered, creating a need for many
other objects that are currently on disk, to do some work. This would
introduce a lot of work for, as it might seem to the user, a trivial
operation. Even if all work done is needed and would have to be solved in
more cubersome ways on other systems, this could take much I/O and
computing power.

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

Yes... objects and OH's are sorted in the system tree. Then it's just
interfaces left... and that shouldn't be a major problem.

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

Programmers don't have to deal with objects inside their programs... they
are only needed in communication with the rest of the system... the only
solution to the problem, I think, is to keep an open attitude, allowing
improvements from app developers. In this way objects could keep a popularity.

I think I've failed to explain OH's good enough... it's more generic and
flexible than anything else I know about. I'll see if I can clarify when I
know a little more exactly _what_ to clarify.

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

Yes, popularity is crucial.

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

This was maybe not much of a advantage after all. I was thinking about
FS'es as not being treated at all differently from other things on the
system, but other OS'es could do that too.

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

There's no need to learn any OH... You only have to use the interfaces, and
they are used just as ordinary API's.

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

If my clarification did not lighen your critique, please specify exactly
what would make it bulky.

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

Not? OK, I'll give some examples.
* Use compressed data just as ordinary directory structures, since the OH
for compressed data can make it all transparent.
* Transparent networking makes remote systems look like just another part
of the system tree, allowing you to do everything remotely, without any
need for FTP or rlogin or any other special tool.
* Functions can be replaced easily and have a system-wide effect. Have all
tree structure windows in a GUI replaced at once, or upgrade all text
windows without any need for applications to care about it.
* Have files with intricated data structures show their contents as a
sub-tree in the system tree, and in some cases have the contents changeable
the same way as everything else, without the *need* to use the app's
interface.
* Flexibility... you want to add support for a new device? Plug it in,
write an OH for it (like a device driver...) giving it some interfaces (or
define your own interface if nothing existing fits), and create an object
(runtime) that maps to the physical device. Then you're done. The system
takes care of accessibility/security and sharing (allowing the modes you
say are possible).
* Another flexibility example. To move to a new GUI, install it in the
system tree and redirect all related object types to the new OH's. With
also all OH's in the systree, it's no problem to distinguish which object
types to redirect. If now only the new GUI uses the same interfaces - which
should not be a limit, since the interfaces would be strictly logical for
their purpose and generally needed - applications will run just as happy
under the new GUI. Or why not let different GUI's live and act in different
branches of the system tree. The principle of locality makes them happily
coexist.

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

It looks like there's a general move towards MFC among Windows
applications. But still there's many programs that implement common things
themselves... and often lacking in features, stability and compability.
I'm rather inclined to move common code from the executables to system-wide
"libraries" with well-defined interfaces.
If you implement something that is useful in more than one app, you can let
everybody that codes for the OS take advantage of it... yes, DLL's do that
too, but by using interfaces, others can even find the new possibilities by
simply looking at what the objects can do (the supported interfaces and
their functions), and use them directly throu the scripting language. If
the new features conforms to standard interfaces, other applications will
know how to use them, without upgrades.
This is my approach. Lift out common code from the applications and shared
libraries, and make them availible, understandable and exchangable in the
whole system. Not as fast, but more space-efficient, flexibile and
worked-throu implementations (since only done in one place). It also makes
common code less subject to language-specific implementations.

>- 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 ? 

Yes, relatively. Since my system uses common interfaces to even advanced
structures, interaction should be possible to a higher degree. My knowledge
in UNIX is not very great, so I'm on thin ice when comparing. This is just
what I think.

On the other hand, isn't everything we ever say just what we think? ;)

binEng

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