ORG, ROI, pem - Spec. 03/16/93, defence (long)

[Peter Mueller]

Hi, 

I've read comments about my specification on ROI. Let me comment things, which can be 
done on the fly. Though there are some suggestions, which require a deeper look.
I will think about them this weekend.

comments to arff:
> [...] with nucleus do you mean the innermost kernel?

In previous mails there was a kind of call to provide a kernel-within-the-kernel which 
should handle the most elemental stuff. I suggest the name `nucleus' for this `little' 
kernel. (But that's not my creation. It's used in several other OSs ... :-)

> I'm not sure, that the kernel should provide IPC.

IPC requires copy of data from one into another address space. Thus the entity providing 
IPC must have enough privileges to write into foreign data space. The question, where 
the entity actually resides must be answered with the requirements in mind. IPC must be 
fast. Very fast. Maybe it is possible to provide the fastest IPC within a device (though 
there maybe is an overhead: the device is `scheduled' by the kernel. Thus kernel
calls are made which contradicts the requirements of IPC.) Nevertheless, the idea to put 
IPC in an IPC-device sounds good. Note: IPC in current systems is the main factor for 
performance lost.

> Identifying objects by description ...

With `description' I mean a possibility to request some kind of service with a given 
quality. If you know of transport protocols as they are specified in - I think - OSI, 
you will know what I mean. You can distinguish between at least 4 classes of transport
protocols, each providing the same service, to transport data from one to another
entity. They differ in the handling of, eg., error conditions. Where the first class 
assume that the underlying communication medium requires no error handling at all, the 
last class assume just the opposite. The medium isn't safe, thus, it provides error 
checking and correction. The first one is fast, because there's no error handling 
overhead, whereas the second is slower but safe.
   An object can request a transport protocol with a desired quality. If you declare the 
description of the desired quality as an own language, then you may call it `description 
language'. But there's only a change in the request to the directory (dedicted to Fare').
To the name (for example `transport') a description of the desired quality is added. The
directory can then choose the right object, fulfilling the requestor's needs.

> Identifying objects by value.

Maybe I should have said 'identifying by state'. With this you can ask for a server which 
is in a desired state. (Sorry, I currently have no example by hand.)

> Password stuff

Simply rename what I've called 'name' into 'ticket'. If an object
sends a request it must have the right ticket, so it is allowed to
ask for the requested service. (This leads to capabilities. Please
give me the weekend to think it over in more detail.)

> Actually, I liked the draft more than the example.

Sorry. I bet your pardon ... ;-) And thank you: You gave me the
word I've been searching for: It's more a draft than a spec.
 
> Following your concept each object seems to be very "private".
> A task knows what he wants (by name?/!) and uses it.
> Now another task need the same service, but he doesn't know the objects name.
> How can he know how to use it then?
> 
> It looks like we have to define several types of base objects with a set of
> minimum defined functions to let it become an object that can be used by the
> name server as a public object.
> I don't think a task should know everything about the object he want to use.
> 
> I'll give you an example:
> 
>   Take a picture viewer. It doesn't contain any code itself to show
>   any picture, he relies on objects that he can reach through the name
>   server.
>   How can it know what objects to ask for without a uniform description
>   language. How can it know how to use the object without knowing something
>   about it's capabilities.
>
> Maybe I have missed something fundamental (trying desperate to reach the Tao).

Ok. I will do what I can to let you reach the Tao. Here is, how I would include
your example in my 'system'. Let's first make two assumptions:

1. The picture viewer knows the format of the picture.
2. There are no other objects, which want to display pictures (I come back to
   this point later).

The first points enables the viewer to choose the right display server. With the
second point there's no need to make all possible display servers available via
a name server. You can manage the viewing of the picture with less overhead:

a. The viewer receives a request to display a picture, eg. via ROI.
b. Depending on the picture's format it creates a new instance of an appropriate
   display server. (It actually knows the server's location, hence, it must NOT
   ask any name servers.)
c. After displaying the picture, the server terminates (or, after the picture must
   no longer be present).

Now let's change assumption 2 to the following:

2. There are other objects, which want to display pictures.

As displaying a picture can be a very application dependent task, you can simply
let all objects create their own display server instance. (Well, then you might have
several copies of the same server, each running in its own name scope.)
As each application knows the name of its server, there are no identifying problems.

If you don't want to have multiple copies of the same display server running the 
following scenario is what I would expect.

Some nice human have made a display server available. He/She will then provide two 
objects: First, a server and second a client object. (The latter must be made available
for all those other humans, designing applications which want to display a picture.) 
In the applications this client object is used to request services from the newly 
available server, which must be present in the appropriate name scope. 

The next step is to make several displaying servers available within an application. You
mentioned it already: There's a base object, describing services which must be provided
by a display server. The application creates an instance of this base object, and identify
the right server by its name.

I don't think that providing base objects is such a great problem. It's the key issue in
object-orientated design. So each one, developping servers or devices (here they are again!)
should first develop a useful abstract base class.

> Correct me if so.

Dito. :-)
> 
> Arff
> 
> PS. Peter, I must say once more that the only thing that has brought MOOSE a
> similar step forward was rev. -72 :-) from Dennis, keep up your good work,
> both of you!.

Thank you.

comments to Fare':
==================

> (Hey ! I did answer your message; didn't you receive my reply ?)

No, I don't.

 
> I'd call it only Meta-ROI; for you don't say anything about direct ROI, but
> only about how to get to be able to do ROI.

I will refer to this terms later, when you mention, that "ROI and IPC are just
the same". Sorry, they are not.

> 
> 
> > 2.2 Object Location Transparency
> > --------------------------------
> 
> >    Most objects within MOOSE are location independent; it is not definitely
> > clear where the object exist at a given time. Additionally, objects are
> > created dynamically in a non-deterministic fashion.
> >
> >    Mechanisms are needed which provide a mapping function from an object's
> > description to its actual location. These mechanisms are provided by a
> > special kind of server object, the NAME SERVER. Name servers know the
> > absolute locations of their objects and make them transparently available
> > to other objects. 
>  The "name server" name takes into account only part of the various aspects
> of this object. This object is also a client to memory, to any library/module/
> object publishing to it, etc. And it's a very technical term. I prefer the
> "dictionary" name, or something like that (well, after all, let's have this
> name fight a minor issue; Dennis will ultimately decide).
> 

I don't think, that "name server" is a very technical term. But you're right: 
There's no need for a name fight. We can use dictionary. (But how would you
call an entry within this one? A key? Index? ... :-)

> 
> > 2.3 Efficiency
> > --------------
> >
> >   Therefore ROI must be very efficient to minimize the
> > remote invocation overhead. This can only be reached if very efficient IPC
> > mechanisms exist. Thus the kernel must provide very fast IPC (which is to be
> > specified in another release).
>  Well, to me, ROI & IPC ARE JUST THE SAME.

Now it's time to separate the terms ROI and IPC. ROI is very similiar to the well
known RPC. It's only a concept, defining how one object can invoke another object's
methods. There is no specification on how this is actually done. There are no send
or receive primitives. To provide ROI there must exist these mechanisms. As RPC is
packed upon transport protocols, ROI must also be packed upon protocols, etc. (And to
Gary: After thinking some days, I agree: RPC is NO implementation detail. I think,
I've mixed up real RPC implementations with the RPC idea.) Well, actually ROI is
a special kind of RPC, used in object-orientated environments. Because RPC isn't
enough anymore (and to avoid mixing up invocation with procedure call) the term ROI was
minted (my dictionary told me that's the word I would use in German ...).

Again, ROI is only a concept. The actual definition is done via IPC, where an
invocation is mapped into send and receive primitives. Thus, IPC is nearer to
implementation than ROI. In an IPC specification you will see definitions of
communication primitives, protocols, and communication units.

> 
> > 3. Object Identification
> > ======================== 
> 
> >    To give access to a server's method the server must be known to all
> > possible clients. Thus the client must have the functionality to identify
> > the right server. Identifying can be done in several ways, eg.:
> 
> >      1. by name
> >      2. by description
> >      3. by value
> absolutely agreed; you can ask the dictionary to find an object considering
> restrictions on its name, its type, and/or its value. So that's not only a
> NAME server, but it's an OBJECT server.

Oh, let's simply say dictionary. There's no need for the term OBJECT SERVER.

> 
> > 3.1 Nameing
> > -----------
> 
> >  A server can be unambiguously identified by its name. A `name' is a unique
> > identifier within a given context, its `scope'. Note that several scopes may
> > coexist at the same time, eg. each application may have its own name scope.
> > This facilitates that multiple objects with the same name may coexist, but
> > each one must reside in its own scope.
>  Well, I'd see it more like an structured object language symbol table:
> the server returns (if it exists) the latest (with respect to structure
> hierarchy) object fitting the name and typing restrictions.
> >
> > 3.2 Name scopes 
> > --------------- 
> 
> >   A scope is created whenever a name server is started. Thus all known names
> > to a name server form the name server's scope. An application, which create
> > a name server have the ability to build up its own scope, allowing it to
> > redefine names as needed. Eg, it's possible to `overwrite' an existing file
> > server to an application specific one, which always encrypt data on writing
> > and decrypt it when reading. The application's file server can then be an
> > inherited file server, which is specialized for encryption. Of course it can
> > use methods from the `traditional' file server.
> More generally, and as I previously posted, dictionaries are a virtual
> recursive type, so that anyone can create a new kind of dictionary (example:
> DOS partition dictionary; ZIP file dictionary; encrypted dictionary, etc),
> and any object can use any dictionary as part of it's own dictionary.
> 
> >    One question arises: What is the first scope OR where is the location of
> > the first name server?
> No need for that; each object is provided a dictionary upon its creation.
> The bootstrap's object dictionary recursively contains everything; it may
> give part of it only to sub-objects.
> 

Actually, I don't see any difference to my approach, besides the fact, that you want
each object to have its own dictionary, whereas I want to have each object decide
if it needs one. If there's the need then the object can create a new dictionary
instance, simultaneously creating a new scope, which may overlay the previous one. 
 
 
> I don't agree ; here is my proposition:
> 
> >         +-------------+    Kernel   +----------------+
> >         | An Object   |<----------->| its dictionary |
> >         +-------------+    = ROI    +----------------+
> > Fig. 3 b
> 
> >    A DNS location request solved by a kernel service is shown in Fig. 3. For
> > simplicity only two privilege levels are shown, user and kernel level. 
> My figure has no privilege levels. No such thing is needed. Kernel is ROI.

See my comments on ROI and IPC.

   
> > To all of you, who want to see a more `implementation' oriented version 
> > I will now present examples, how an user should be able to use ROI 
> > in his/her application. All definitions are specified in a syntax similiar 
> > to those of C++. Note: This is still a conceptual model! At the end I will 
> > present problems which arise at this layer. 
>  C++ is good, but it is unstructured (all data global or local), and allows
> object handling only at compile time; no execute time handling is provided.

Again, this is still conceptual! I used C++ syntax, because I'm knowing it. I 
only want to show, how I would use ROI in an implementation layer ...

 
> > Problems 
> > ======== 
> >  
> > What, when public methods of a server call private methods? 
> > ----------------------------------------------------------- 
> >  
> >    Private methods are able to change the server's state. There must be 
> > mechanisms which avoid an influence from one client to another client's 
> > point of view to this state. Thus, each client must see it's own server 
> > state. 
> ?
> Each client manages its dictionary itself; but the dictionary is given
> objects at the beginning.

You still have the problem, what to do, when a remote object is called and the
called method changes the private state of the object. Another object, invoking
methods from the same remote object will see the changed state. That is not
desired. The private part must be separated for each calling object.

> 
> > What, when a server chooses a name which is already occupied by another 
> > server?
> The older one is hidden by the newer; See Pascal and such structured
> languages.

I don't think, this is a useful mechanism. Simply use creation of new name
scopes to hide equal names. If you hide a previous publication a client
cannot reach this "older" server.

> 
> > ----------------------------------------------------------------------- 
>   
> >  This leads to a name conflict, which must be solved. The name server will
> > deny the request and the server is not published. Thus, the provided
> > services are not available. 
> I prefer the previous solution; or you may choose between those two.
>   
> > What, when a client cannot locate an appropriate server? 
> > -------------------------------------------------------- 
> Then it cannot use it !
A little bit too fast ... ;-)

> 
> >    There are two reasons for this problem: First, there's no server 
> > available. Then the client can simply create a new server instance. This
> > instance will then publish itself to the name server, which was asked by the
> > client. In this case the client knows the server's location. There's no need
> > to ask the name server again. 

One solution.

> >  
> >    Second, there's a server using the name, but which is not appropriate
> > because it have the wrong type. There must be a mechanism which ensures
> > that the returned server is useful for the asking client.
> Well, you see there's a need for typing!

Yup. I totally agree. But that's fundamental to OO ;-)

> 
>  To sum up my comments: I totally agree with what you wrote (whereas I stick
> to the dictionary name for NAME SERVER; name server is too technical;
> dictionary is just fine). HOWEVER, this just isn't enough, for names don't
> suffice, and we have to define what a direct link is, and include typing into
> it; for if we have no typing, there is no objects.

Ok. But in ROI the typing mechanism is an assumption. ROI uses the OO paradigm 
to invoke remote methods. Typing is implicit. So, a ROI specification must not
necessarily include how typing is done.

>  So let's define objects, which are our main problem.

That's a part of another specification. Need not to be done here.

Bye,

Peter