[unios] Re: Comments Concerning mOS Introduction

[Anders Petersson]

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

>From: Faustino E Osuna <osuna@CTC.Net>
>
>I'm assuming that the information included in this document is the proposed
>elements of UniOS.  (I've seen mOS mentioned in  the past posts, but I
>haven't really been keeping up :( so I'm sorry if this post sounds moronic.)

Yes, the information given is completely up-to-date, even if more brief on
certain areas than necessary.

>> Object axioms
>> Objects live until they are deliberately killed, or all use of them
>ceases.
>> To own an object (be the parent) is also counted as using it. That
>> means that if the parent is killed, so are all children, and the
>children's
>> children, and so on.  When an object is removed and someone uses it,
>> it can either still be removed and users are notified, or it can just be
>> released by its parent, and so live until not used anymore.
>
>So in essence, we have a tree of objects?  But other objects (alien-objects)
>can access [point to] the tree's sub-objects.  Will alien-objects, too, have
>access to the sub-object's children?  (I'm assuming yes, but we know what
>assume means.)

Yes, one single tree of objects - the system tree.
To be outside the system tree, the alien objects would have to exist on
another machine. Those would then be representated on the system throu the
OID server that is the network manager, so they too become a part of the
system, in a way.
Or maybe you mean other, non-related system objects when you say
"alien-objects"... anyway.
The whole sub-tree is normally not given out with the access to an object.
Both alternatives should be possible, thou. I don't know exactly how,
probably by giving or denying access to an interface in the used object.

>> An object by default has all rights to all objects under it.
>
>Meaning objects can't protect or hide some of it's own member functions/data
>from the parent?  Or does that mean that only the original owner of that
>object can destroy it, create it, alter the public data, etc?

Objects can't usually hide anything for its parents (scaring, huh :) ).
Everyone that has got permission to can destroy an object. The same holds
for creating objects. From the beginning, only the parent, grandparent, and
so on have permission.
There an object interface, with methods for moving and destroying the
object and creating children. This still need some development, but the
point is that such actions should be protected/accessed in the usual
interface way.

>> Objects can be notified when objects they use are altered.
>
>What would be an example of this?  If "sub-object" alters
>"sub-object->sub-object" then the "parent-object" will be notified? Or if an
>"alien-object" alters one of the objects found on the object-tree branch.
>If that's the case, then what if the parent object doesn't want the
>alien-objects, which don't have full rights to that child-objects, to alter
>it's branch-objects? Shouldn't the alien-objects request the parent-object
>for the right to alter the sub-objects? (I hope you understand that because
>I can barely understand it.)

I'm unsure about what you mean with "sub-object->sub-object", but I guess
you mean the child of the first child.
The first of your questions: No. The "grandchild" is altered, which the
parent doesn't use. The child is notified, since ownership means use.
Question #2: Unrelated objects apply for permission. Whatever interfaces
they get access to they can use freely. Certainly access to sub-objects
must be limitable.
Question #3: Unrelated objects just apply for access to a certain object.
The security module grants or denies access, based on the security policy.
Beyond that the design is implementation-specific.

>These are dumb questions, I know, but I'm really interested.

Not as dumb as interesting.

binEng

PS. We need a good terminology about this!!


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