ORG,ROI,pem

[Peter Mueller]

Hi,

(hope, I've used the right code in my subject line. To Fare': Correct
me if I'm wrong :-)

> >> >    An RPC call will contain information such as a remote object name,
> >> > the remote object's method name, permission information, and a set of
> >> > arguments to the method. The invocing thread is blocked, the message is
> >> > delivered to the destination object, the object executes the method
> >> > with the given arguments, and passes the return value (or error code)
> >> > in a message as a reply to the calling thread. Note that passing
> >> > pointers isn't useful, since objects have disjoint data spaces. There
> >> > are, however, techniques to improve performance when passing large data
> >> > items.
> Again, I suggest to implement a standard second way for errors and exceptions,
> with an exception handler routine stack.

If I'm on the right track you want to establish a second communication link in
addition to the main link for error and exception messages? If so, it's just 
uneccessary. If in a communication a faster link is needed let the objects decide
to establish such a connection. If I'm on the wrong track, ignore this paragraph.

> 
> >> That's again too deep. Naming should be done by another object, eg. a 
> >> NAME_SERVICE. This must exist, because objects must be able to publish 
> >> themselves or their methods to the outer world. Thus, an object X which
> >> want to be published invoke a methods of the NAME_SERVICE, which makes X
> >> known within the NAME_SERVICE's scope:
> >> 
> >> +---+              +--------------+
> >> | X |---publish--->| NAME_SERVICE |
> >> +---+              +--------------+
> >> 
> >> If an object Y wants to use X it first must determine X's location. Therefore
> >> it asks its NAME_SERVICE, which returns X location:
> >> 
> >> +---+                           +--------------+
> >> |   |---ask for X's location--->|              |
> >> | Y |                           | NAME_SERVICE |
> >> |   |<---return X's location----|              |
> >> +---+                           +--------------+
> >> 
> >> Now Y can simply invoke a method from X:
> >> 
> >> +---+             +---+
> >> | Y |---invoke--->| X |
> >> +---+             +---+
> >> 
> >> With this design it is possible only to contact published objects. More: You
> >> have to contact the right NAME_SERVICE to get a desired object's location. 
> >> Think of several applications (which are O B J E C T S), which all have their 
> >> own NAME_SERVICE available. Several objects with the same name may coexist
> >> even with different functionality but the application's local NAME_SERVICE
> >> secures, that the application is only able to invoke methods of well known
> >> objects. 
> >> 
> >> Of course it is possible to "link" NAME_SERVICE objects. So it is possible to
> >> create hierachical or other name scopes. If an object's location cannot be
> >> resolved within the first (ie. smallest) scope the next higher NAME_SERVICE
> >> is automatically invoked.
> >> 
> >> What I currently left out is, how an object received knowledge of "its"
> >> NAME_SERVICE. (Or to be precise: Which NAME_SERVICE provides the knowledge
> >> of the desired object.) If you want, I can try to present you a design
> >> idea.
> again, I do agree with Peter's remark, but else support Gary's views (perhaps
> are we going to agree upon that 'dictionnary' stuff as I call it - call it as
> you may).
> 
> >> >    The thread is the basic unit of execution within an object. A thread
> >> > can invoce a method of another object via an RPC. The calling thread is
> >> > blocked until the call is completed, but the other threads are allowed
> >> > to continue. The call is received by a thread in the target object that
> >> > waits for calls to that particular method. Threads can create other
> >> > threads to execute while others are blocked. This allows the object to
> >> > continue processing while waiting on the result, while maintaining
> >> > procedure call semantics.
> >> 
> >> That's again too deep for the first ROI specification.
> Well Gary's just anticipating on implementation.
> 


> >> >    An object is created by an RPC call to an object with access to the
> >> > scheduler and resource allocator. An object with such access may also
> >> > destroy an object by descheduling it an deallocating its resources.
> >> > Each object will have an initial set of object names. This will
> >> > generally include the name of an object that holds the names of other
> >> > objects. 
> >> 
> >> Hmm, what does object creation have to do with ROI? (BTW: In my opinion
> >> an application which cannot receive access to an object, simply create an
> >> instance of a new one. Then the object can make itself available via the 
> >> application's NAME_SERVICE or a predefined one. Of course the application
> >> object already know the object's location and can invoke methods immediately.)
> >> 
> >> > Each object should include a method to determine the names of
> >> > its other methods.
> >> 
> >> NO! Publish all methods which should be accessable by other objects to the
> >> NAME_SERVICE! Seperate the services (provided by objects) and it's management
> >> (provided by NAME_SERVICEs). Without such separation each time you include
> >> a new service you must also change the determination method. Don't mix up
> >> services and their availability.
> Uh, well, both ! It may be useful to ask the method's name directly to the
> object without having to look through the whole table (but both methods are
> equivalent; you can build the name list from the objects with a method list
> method; or you can build a method list method from a name list; so to me,
> that's up to implementation)

No, it's not the same. If you have to provide a method, which holds all information
about the object's functionality you are forced to mix implementation and 
access within one object. If we use oo, we should separate both. (BTW: How do
you ask for an object method's name if there's no NAME_SERVICE, giving you 
information of the object's location?)

Next, oo means to design from base with minimal extensions. As Fare' said, a
functionality method can simply be provided by asking name facilities for known
objects and building up a method list (which must hold object's location [its NAME]
and the name of the method). This seems to me to be a minimal extension.

Last, if an object have once asked for a remote object's location it can address it
(ie. invoke its methods) directly. There's no need to ask the nameing facility more 
than once.

Again, "directly" means, that there are IPC (and know I mean IPC) mechanisms, which
make such method calls possible. This includes, address resolution, routing, 
sending, and receiveing (which both should be synchronous). IPC should be included
in the kernel. There's a must that IPC must be as fast as possible. 

If there's interest, I will set up a design specification during the next week. 
(I know you will all be happy with that ;-) But first I want to wait a few days and 
give you time to throw in your ideas. PLEASE: I know you are all sitting in front of
your keyboards, willing to answer to all those ideas as fast as possible. I want you
to think it over. Don't think about implementation, how it can be done, or what 
problems may occur in real programmer's life. I want you to think in a higher 
level, abstract, and object-orientated. Think in terms like: services, invocation,
functionalities, methods, and - of course - objects. Imagine a system, where no
communication costs exist (uuh, you will flame me for that), where you have no 
memory restrictions, or stuff like that. Think of an ideal system. (Again: Let's
first say what we want and then see, how we can get it.) Start up a drawing program
and draw pictures with boxes as objects and arrows as communication lines. (Think
about a possibility to send it via e-mail :-)

Now, read again my vision of a NAME_SERVICE mentioned above, get yourself a cup of
coffee, and ... FLAME ME!

Cheers,

Peter