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.