fantastic!   I have a couple of questions:  Do we need to provide a 
capability interface to plugin code?  Could this help us support 
function callbacks, into the image, so we could use squeak as a shared 
library to another program?    Forget about my authentication 
ramblings, please.

cheers,
rob

PS.  Mark, I am adding handling of these three messages to the CapTP 
(id -> class).  Does this conflict anywhere?

		at: 13 put: CapTPAvailableProtocolsMessage;
		at: 14 put: CapTPSwitchProtocolMessage;
		at: 15 put: CapTPAcknowledgeProtocolMessage;



On Sunday, January 26, 2003, at 12:29 PM, Mark S. Miller wrote:

> 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
>
>