ORG, ROI, pem - Specification 03/16/93

[Andreas Arff]

> Howdy!
>
> And now happy reading,

Thank you Peter, you have given MOOSE a huge kick forward, I want more of this
stuff.
Just some few comments on your proposal, which are mostly very good.
A question though, with nucleus do you mean the innermost kernel?

> Peter
>
> ----- Cut here -----
>
> R e m o t e   O b j e c t   I n v o c a t i o n
>
> Specification Release 0.00 (03/16/93)
>
> 1 Overview
> ==========
>
> 2 Design goals
> ==============
>
>    The following points give an overview of desired characteristics for ROI.
> Thus, ROI should be:
>
>      1. general
>      2. object location transparent
>      3. very efficient regarding communication costs
>      4. user-friendly
>
> 2.3 Efficiency
> --------------
>
>    As one design goal of MOOSE is to provide a highly dynamic system, where
> components are added on the fly, ROI will be a highly used communication
> mechanism. Almost all traditional operating system services are provided by
> independent objects. 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).

I'm not sure I agree with that the kernel should provide the IPC. Remember
to keep it small and clean. I would rather put the ROI into its own ROI-device.
(oooh no, don't start to talk about devices again Andreas :-)

> 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
>
> This specification will only handle the first one, nameing.

I many ways the other two are more important. I'm sure you have thought alot
about them.
For 2. must we make a ROI description language? I'm not sure of how you ment
this to be done.
For 3. Should we provide the developer with a list of numbers, each equal to
one object-type/object, if this is what you mean.

Please elaborate point 2 and 3 a little bit more.

One thing that I think should be possible; make an object private. You have
to know a "password" to use it or something like that.

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

Actually Peter, I liked the draft more than the example:-).


Maybe I have misunderstood some of the ROI concept so here follows a brief
discussion of my thoughts vs. your.

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).
Correct me if so.

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!.
DS.
  Arff
sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@dhhalden.no--