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

[Peter Mueller]

> From winikoff@cs.mu.OZ.AU Thu Mar 18 13:32:37 1993
> Subject: Re: ORG, ROI, pem - Specification 03/16/93
> To: moose-programmers@sfu.ca (Moose Project)
> Date: Thu, 18 Mar 93 22:29:01 EST
> From: Michael David WINIKOFF <winikoff@mulga.cs.mu.OZ.AU>
> X-Mailer: ELM [version 2.3 PL0]
> Content-Length: 1255
> 
> >  
> >      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.

I've mentioned that I use the terms client and server, because their functionality
is well known. When an object wants to invoke a remote object's methods, the first one
requests a service from the latter. Maybe I should have used the terms invoker and
invokee ...

AND: ROI is *no* system call. It's a conceptual model, which allows an invocation between
two remote objects as if they were local. 

> 
> We shouldn't constrain the user of ROI to a client server setup.

Ok, I suppose you get stuck, because I've used the terms within my examples, too. If you want
to provide mechanisms like callbacks in RPC you can do it in such a way:

	LOCALOBJECT.doSomethingRemote(myself);

myself is then the reference to the invoking object. Now the invokee can invoke objects from
the invoker (in the remote object):

	REMOTEOBJECT::doSomethingRemote(LOCALOBJECT &caller) {
		caller.doSomethingElse();    // This can be seen as a call back ...
	}

So, there is the possibility to communicate in both directions. ROI will give no constraints
about the communication style!	

Sorry, that I've used these two terms which leads to misunderstanding. I will keep the next 
specification cleaner.

Cheers,

Peter

P.S.: Can someone please explain what `IMHO' stands for?