An analogy [Was: Re: Specifications]

[Oleg Cherevko]

On Sat, 1 May 1999, Tril wrote:

> > You solve the security problem by saying that the client will not be
> > allowed to read the reference. By what can you do with it then ? 
> 
> It can use the reference to do any legal operation on the object.  It just
> can't find the ID for the object.  

Do you mean that the client will have sort of a handle (i.e. locally
unique id meaningful only to that client) to each object it uses?

If so, the analogy to an ordinary Unix filesystem may be helpful here.
In the Unix filesystem (=persistent store) files (=objects) are identified
internally by i-node numbers (=IDs) which are invisible to the processes
that are clients of the filesystem. To request an operation on a file
(=invoke a method of an object) one has first to locate the file in
question via some mechanism [by specifying filesystem-unique path to the
open() call in the case of files/filesystem; (=??? in the case of the
objects/persistent store)], which results in obtaining file handle
(=object reference?). This handle serves as local id of this file to
the client process and is related to the filesystem-unique i-node (=ID)
only in the Unix kernel (=evaluator?).

--
Olwi