Lex and Andreas,

This is all very interesting!  I have been pondering this area myself
for a few months - it is the direction I was trying to take the
AddressSpaces I posted a few weeks ago (during the CSFramework post
which, BTW, was broken ;-).  Another very interesting piece is Oasis, by
Les Tyrrell at:

http://oasis.canis.uiuc.edu:8080/Oasis

OasisModules isolate the semantic model from the rest of the environment
for analysis purposes.  Les' quick tour includes the isolation of the
dangerous code module known as LindaTalk.  :-)    Les, is this
orthogonal stuff?

My AddressSpace spike was to try and redirect all message sends to a
foriegn object, which would be an object in a different SandCastle. 
This is done with an imperfect proxy (subclassed from Object rather than
ProtoObject, to avoid inspector problems for metalevel methods) called
an ObjectFront.  This Front would redirect the message send to what I
termed an ObjectBinding, but should really be named a Redirector or
something.  This binding can be viewed as a protocol stack to the
object, as you can compose multiple constrained behaviors like
persistence, security, remote, synchronization.  I was thinking that
this solution could allow for either an ACL based security mechanism or
a Capabilities based mechanism, even though I didn't know that term
yet.  In thinking about a Capabilities model, there is an initialization
of the SandCastle, which can grant a certain level of Capability,
followed by additional operational grants of further Capability.  

To represent this capability, instead of exhaustively subclassing
proxies, we can take some concepts from Oasis (or port it for that
matter), and construct Shadow classes, in this SandCastle, which contain
method dictionaries with subset protocols.  These CompiledMethods can
either forward to the right SandCastle, where the object really lives,
or execute directly on cache state.

This architecture seems to require nested environments, within which the
compiler can resolve names.  The shared immutable space can be a
universal space (Magnitude, Collections), while the more dangerous
classes can be in a specialized environment, which only returns
redirected Classes.

I need to do more reading of Capabilities and the details of block
objects and the like to continue to contribute my opinions
intelligently.

regards,
Robert

Lex Spoon wrote:
> 
> Thanks for your feedback!
> 
> You're right, I've largely ducked the issue of what exact proxies will
> be needed.  I've been focussing on how one would get the system set up
> to begin with, but figuring out what exactly the proxies will be is
> critical.  Your ideas about a capability-distributing factory, along
> with some way to send a request to the user for more capabilities, sound
> very interesting.
> 
> At the least, though, a SandCastle will need capabilities like the
> following:
> 
>         - block and class proxies, just because direct access to these can
> break the basic model
> 
>         - a display to  draw on.  The proxy probably draws to a form, and the
> form is periodically posted to the real Display by a morph in a separate
> thread.
> 
>         - a queue of input events.  Probably this is just a queue that is fed
> to by an outside morph.
> 
>         - compiling code.  For Player's to work, I've been informed that it's
> necessary to compile code as you go along.  Probably, though, there will
> be a "player compiler" or somesuch, which can only compile things for
> players defined along with the sandcastle it is acting for.  I'm not
> sure what the exact definition will be, but at least with a capabilities
> architecture, we get to play around with what exactly the definition
> should be.  :)
> 
> On your other query, the reason I made the shared immutable space
> explicit, is to eventually work towards an a formal description of the
> system works.  If this wasn't project #3 on my priorities at the moment,
> it would get done faster.  :|
> 
> Anyway, the core invariant of the formalization will be that a sandbox
> remains completely separated from the main image.  Integers, characters,
> and symbols break that invariant.  It's okay, though, so long as you put
> restrictions on these objects.  Notably, in the current system,
> Characters and Symbols do *not* meet those restrictions, so there is
> some work to do.  Also notably, something needs to be done about floats.
>  I think in this case it's easiest to not make them sharable.  Proxies
> can just make a copy of any float they wish to pass to the other side.
> 
> Lex

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!