At 07:14 AM 1/26/2003 Sunday, Robert Withers wrote:
>Mark, you seem to be saying that we wouldn't have to change the vm, in order 
>to 'host' a capability language, and write an E-interpreter.  

I'm catching up. Some of this is addressed in my previous post. To recap briefly:

You can write a Kernel-E interpreter, and I am proposing this as the place 
to start, as a development strategy. The goal is indeed to change the vm, 
but not I think in the way you have in mind.

>While that would be very interesting, my intension has been to transform 
>squeak itself into a capability language.   This would require some VM 
>changes, to create opaque references, and MOP changes, to handle the fact 
>that Inspectors won't be able to look inside an object.

I think it's a mistake to try to gradually evolve the one Smalltalk vm in place 
into a capability vm. As long as it's a single vm, it will have to continue 
running old code, which will prevent it from having the properties needed 
for a capability vm. Fatal question: Would your vm support mutable class 
variables? If the answer is yes, you will never have a good capability 
system. If no, you break too much old code. And if you're willing to burn 
the diskpacks and leave behind the old code, then there'd be even less 
reason to evolve the vm incrementally.

Instead, I propose building a wholly new vm (Kernel-E) to co-exist along the 
old one. Any individual behavior is coded and executes on one vm or the 
other, but objects in either can call objects in the other. The Smalltalk vm 
and all legacy Smalltalk code would then, from the perspective of Squeak-E, 
just be a very large TCB, to be reduced in size incrementally over time by 
rewriting libraries in Squeak-E according to proper capability discipline.

TCB implies you're always at risk to any of the Smalltalk code you run, just 
as you are now. None of this changes that. But you can load code into the 
new Kernel-E vm with impunity and immunity, enabling "mobile code", ie, safe 
executable content. Eventually, you should stop loading new code into the 
old VM.


>My motivation in suggesting separate segments (vats), was that squeak should 
>be able to host concurrent users.  

Good. But separate object memories doesn't contribute much. E supports 
multiple vats per JVM all in one address space.


>A vat, to my way of thinking, was an 
>authenticated space, in addition to having the concurrency and persistent 
>properties.

I don't understand this.


>  A user with certain amount of authority could create a vat, and 
>be able to run with other vats in one image.

In E, the power to create a vat implies only the power to use resources and 
obtain genuine non-determinism, which is interesting but not relevant to 
this discussion. So present purposes, the power to create a vat may as well 
be freely accessible in E. I don't see why one might want it otherwise.


>Squeak would then have a 
>running system mode segment that could issue machine resource capabilities 
>to the hosted users.

?

>If a vat is attached to a process and is this unit of 
>persistence and concurrency, then it is also the unit of exception handling 
>and authentication.

You're correct on the exception handling, and thanks for pointing it out. 
There are certain vat-based exception handling issues, and I often forget to 
point these out.

I still don't know what authentication issue you have in mind.

>  I may be confusing TCB level security (secure 
>communications platform - Trusted Computer Base), with user authentication 
>and security.

I think so.

>If we look at every reference as a capability, then taming squeak will first 
>involve taming each reference.

Think of every behavior (class) as having two method dispatch tables: the 
Smalltalk one and the Squeak-E one. For a Smalltalk class, the Squeak-E 
table will be a taming of the Smalltalk table.

Now, think of the two VMs as providing two different method call 
instructions. The Smalltalk call dispatches according to the Smalltalk 
behavior, and the Squeak-E call dispatches according to the Squeak-E table. 
When a Squeak-E table contains a method written in Smalltalk, the method is 
then run on the Smalltalk vm. Therefore, the one call stack has to 
transition between VMs smoothly.


>   If my implementation of your eventual 
>sending mechanism is to have any chance of becoming a more broadly used 
>feature, even if the implementation changes, then it looks like there are 
>really two library issues.  First, get the rest of the squeak  library to 
>handle asynchronous objects, and second, to make sure the library is tamed 
>for capabilities.

A good topic for another day.


>How should debugging in a secure environment proceed?   Certainly I don't 
>want you looking inside of my objects, unless I give you that capability.   
>I would want to look inside of my objects and since I own them, I should 
>have acquired the MOP capability to look inside them.

A necessary issue not yet addressed by Kernel-E. What I have in mind is 
based on the KeyKOS/EROS "brand" idea. More later....


>I am rereading the ode (http://www.erights.org/elib/capability/ode/index.html).

Thanks. Warms my heart!


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM