ORG, ROI, pem - Specification 03/16/93
Michael David WINIKOFF
winikoff@mulga.cs.mu.OZ.AU
Thu, 18 Mar 93 22:29:01 EST
>
> 1. general
> 2. object location transparent
> 3. very efficient regarding communication costs
> 4. user-friendly
Huh? My definition of user-friendly says that this is irrelevant to a system
call ...
> Mechanisms are needed which provide a mapping function from an object's
> description to its actual location. These mechanisms are provided by a
We need to specify the description format.
Strings are the obvious simple choice.
> 2.4 User-friendliness
> ---------------------
>
> Users and their applications should not be aware of ROI. If an application
> needs to invoke methods of a remote server it should simply instance an
> appropriate client object. All necessary ROI stuff should be done by creation
> of the client, which then provides a transparent view to the servers'
> methods.
Please keep client-server and ROI seperate.
ROI is a system call (service?) we are desigining which can be used to
implement a client server relationship.
We shouldn't constrain the user of ROI to a client server setup.
I agree with your stuff about nameservers with the reservation that a nameserver
shouldn't have a special role -- it should just be an object that implements
a dictionary of some sort.