Hi Rob,

Rob Withers wrote:
> 
> Hi Stephan,
> 
> I believe we want the same thing, although I would extend the remoteness of
> an object to include objects referenced between squeak processes, in the
> same image.

This is in my mind, too; I've left it out to avoid confusion (e.g. between
Squeak processes oops are directly comparable), but in respect to you this
doesn't seem to be a problem.

> 
> At 03:24 PM 1/6/2002, you wrote:
> 
> <snip>
> 
> >But they are not identical because one is a proxy, the other not: so you
> >need methods like #isProxy or similar at least to get this information.
> 
> Since a proxy acts as a surrogate for the real object, clients of a proxy
> should have no idea that they are talking to one.  This is a Transparent
> Forwarder (papers at ACM).  This should include normal messages, one would
> send to an object, like #class, #==, #size and so on.   On the other hand,
> we would want some management control, over the proxy.  I think of these as
> the location and behavioral aspects of our reference to the object.

> First
> off, the casual user of a proxy should not be managing the reference; it
> should be managed by a manager in a different architectural layer.

Agreed.

>  Of
> course, there could be a proxy control protocol, understandable by the
> proxy, but it would be better encapsulated by controlling the proxy through
> a Mirror.

I like this idea!
Different 'views' of the proxy dependent on the functionality needed/wished.
And with this idea you don't need language extensions for controlling
visibility.

> I can imagine a very strong case where the client should be
> restricted from controlling the proxy.  This gives us the contrary quality
> of Opaqueness, so we can control how much of the underlying object is
> visible to the client of the proxy.
> 
> In the case of a remote proxy, you may also want to control the policies
> for migration/faulting, mutation, synchronization (sync, async-futured,
> async-queued-futured, async-chained-futured like  E), GC.  I am sure there
> are others.
> 
> > > The method nextObject and nextInstance both need to work correctly for
> > > Proxies.  The redirector code (I posted it after the one you replied to)
> > > uses primitives in the way that Stephane Pair discusses.  I got the idea
> > > from him.  All of these system methods are written for the redirector as
> > > accepting the receiver as an argument.
> >
> >To give you an idea about what I'm thinking: Using proxies for objects
> >residing in different Squeak
> >- OS (for me Linux) processes,
> >- processes on other machines.
> 
> and I would add:
> - Squeak processes in the same image
> 
> For all of these we would want control identity (Transparency), security
> (Opaqueness), messaging (Synchronization),  location (Migration), and
> mutation (Transaction)
> 
> >Then I'd have different semantics for e.g. #nextInstance meant as
> >- inside one (OS) process or
> >- between different ones (on the same or different machines).
> 
> I just learned about this protocol recently.  In this case I feel that we
> do not want global iteration of instances, but rather scoped
> iteration.  For instance, if we have two secured object spaces in the same
> image or other images, we should not allow a user, with restricted
> privileges, to gain access to instances of the Frooble class, for instance,
> that is 'owned' by the other object space.  However, the user will
> superuser privileges, should be allowed to access instances in all managed
> spaces.  The ultimate would be to allow the superuser to control a users
> space, but not be allowed to look at the objects inside of it.  In this
> way, you could have a process running on my machine, but I would be unable
> to view your objects.
> 
>  From reading Lex's Islands, and other materials from ACM, we need to
> restrict access to primitives and globals. I think it might be done with a
> security-aware compiler, that wouldn't allow compiling or installing
> primitive methods, or at least system-level primitives.   We would need to
> proxy all globals, and bind processes to a restricted environment.
> 
> Is this a direction you are interested in?

Much of you have written here is *related* to what I have in mind. But the
focus hasn't been on security, but on to ease distributed programming: some
(slightly changed) stuff from another - personal - Mail of mine:

Prenote: 2) below is somewhat outdated, since now I think - after some
discussion with a colleague and after getting a paper (in German) from him,
not my idea - that method wrappers are the right idea to realize
preconditions, postconditions, invariants (he has realized it for VASt
(alpha status, I haven't looked at it so far)). The main problem in 2) below
is to handle OLD values in postconditions. With his method wrapper mechanism
(not described here) this is possible.

------

Inspiration source:
Chapter 30, "Concurrency, distribution, client-server and the Internet", in
OOSC (Object Oriented Software Construction, 2nd edition), Bertrand Meyer.
(I don't have it handy, so please excuse this fuzzy reference.)


What about implementing some of OOSC concurrency ideas in Smalltalk?

In the following I will give a very rough sketch in the spirid of OOSC.


1) Imagine you are able to write:

Foo separate new
-> to create a separate object.

Foo separate instanceNamed: 'MyDB'
-> to get an already existing named separate object.

Message #separate says to the class that it has to give proxy objects back
as replacement for the real ones controlled by another processor
('processor' used in the OOSC sense here). The idea here is to avoid
introducing new Smalltalk language constructs while making the semantic
difference between a separate and not separate object immediately visible to
the programmer.


2) To realize the 'precondition is waiting condition for separate objects'
(cited from memory) we'd need to implement the concept of preconditions -
probably also invariants and postconditions - first. How to do these with
'Keep it simple!' in mind?
First I've thought about a method dictionary in say ConditionObjects holding
the to be conditioned object as inst var and its to be preconditioned
message symbols with their preconditions in an IdentityDictionary, but it's
complicated and has some limitations (e.g. how to directly access inst vars
in the conditioned object, probably we'd have the constraint to always use
accessor messsages).

Much more simple: Put the conditions directly in the class of the
conditioned object!
Idea: Add a prefix to the to be conditioned methods, e.g.
        #doSomething -> #pre_doSomething (*)
, or for postconditions
        #doSomething -> #post_doSomething
, and write the condition as method! It should return #true or #false.
Rationale:
- conditions are located near by the corresponding methods;
- current tools (Browsers) are sufficient to work with conditions at first;
- no extra classes needed here (!);
- easy to check if there are pre/post conditions for methods or not.

While I'm writing a problem comes into my mind: how to express the return
value of a method in its corresponding postcondition method (for
preconditions we don't have this problem)? Hmm, possibly simply by a message
like e.g. #returnValue? Let's not going deeper yet.

To check for conditions we could introduce ConditionObjects holding the to
be conditioned ones, checking for preconditions, calling the method in the
conditioned object and checking for postconditions (I'm leaving invariants
out in the discussion here). Alternatively it could be possible to realize
this functionality without extra ConditionObjects by some support of the VM
(possibly with some extra bits in the object header stating which kind of
conditions has to be checked in general, flags in the methods to selectivly
check them, condition method pointers in the ordinary methods to get
conditions faster, etc.).


3) After we have preconditions realized we could use this mechanism for
implementing 'precondition is waiting condition for separate objects'. Just
some catchwords:
- message queues,
- polling for fullfilled preconditions.


4) The processor concept could first be realized inside one image by a
Manager object starting different Processes each corresponding one
processor. The Manager also would be a location for managing the
communication between these processors. It could reside in a user process
with standard priority and the separate objects running in other processes
with lower priority. Don't know if it'd be necessary to simulate
multitasking for processes at the same priority (Smalltalk systems I've seen
so far just run a FIFO of processes for each priority, just interruptable by
processes with higher priority).
Later it could be extended to work between different images by some TCP/IP
communication with some process waiting for messages from outside: but this
is some harder stuff not necessary to prove the concept.


5) Some notes to an implementation: The system specific (Smalltalk dialect)
as the network structure issues regarding the processor concept (running in
same image, in another image at same machine, on another image at another
machine) should be strongly separated from the logical core. Ideally one
would realize an interface identically for the application developer for
each Smalltalk dialect. And porting should be limited to clearly separated
modules.


(*) In Squeak the $_ corresponds to a left arrow and has #:= semantics, so I
don't know if it's possible to use it in message name symbols there, but you
get the idea.

------


This is very rough (but sometimes I want to share rough ideas, too (this has
been personally first, but you have asked!)); and I don't know if/when I
have time/motivation to work into this direction (life is too short and
there are many interesting things!).
But Meyer's ideas regarding synchronization by the 'processor' concept are
very appealing to me.


Greetings,

Stephan


> 
> cheers,
> Rob
> 
> PS.  I have a decent object comms framework which does rule-based
> substitutions, and has in-pointers and out-pointers stored.  I need to look
> at doing a distributed GC for them.  Also, I am **very** interested in
> Erights and their use of chainable futures, with migratory
> facilities.  That would be fun to build!
> 
...