Robert Withers <withers at vnet.net> wrote:
>> There are two major nexii of control, that we need to handle, and I am
> continually getting them confused.  One nexus is to disallow any
> navigation across an edge in the stateful graph of objects (bindings),
> yet we still need to have a binding.  The other is lookup of a selector
> during a msg send.  This is where the granting of capabilities would be
> implemented.
> 

I think we have different schemes in mind.  I don't think we need to
change the way method lookup works.  Either an object responds to a
message, or it doesn't.  That's all you need to implement a capability.



> Local Elements
> nonlocal immutable elements.
> nonlocal mutable elements.  (some of which are Behavior objects)


I think you can actually avoid having global mutable elements.  For
example, instead of allowing direct access to behaviors, you provide
*proxies* to behaviors.  The behaviors themselves only exist in a single
space.  (The "main image" space in the basic sand castles application)



> Let us create a minimal solution with the most flexibility.  The way to
> do this may be a construction of a tree of spaces which hold Objects,

You seem to be describing what the topology of the spaces will look
like.  I haven't been worrying about that too much, and as far as I can
tell, the basic framework can ignore it.  With the right framework, you
can later build any kind of topology on top of it that you like.

For example, in the basic shipping sand castles case, I think you only
need 4 classifications of objects:

	1. Shared immutables.
	2. main image objects.
	3. sandbox objects.
	4. proxies between the main image and the sandbox.


Four seems like few enough to just wire the thing together by hand.  And
the scheme doesn't *stop* you from having something more general on top
of it.


> If this can be done by subclassing the Surrogate from ProtoObject or
> creating another root from #nil then great.  I am trying to consider a
> cross-dialect solution.  The point in having a binding is to send
> messages to it, right?  Therefore, the alternative approach is to
> decouple a binding and stick a pumped msg queue in between.  Not the
> easiest solution as there are pointer management problems like GC and
> serialization/synchronization problems.

Ah, you want to automate the proxy generation?  (proxy being an object
at the border of two spaces)  I've taken the opposite view.  Proxies are
where security policies get implemented.  Proxies are the place where
humans show their design skills and engineer a new security scheme. 
Proxies would rarely, in my scheme, just accept a message and forward
blindly to the other side.

>From my view, proxies are hard, and should be kept to a minimum because
of this.  There wouldn't be much automation involved, just careful
programming.



> 
> I would like to think of this from a multiuser standpoint.  There should
> be no reason that all of us couldn't be processing, in a protected way,
> in one image.  My concerns are that we rush this without thinking that
> generality through.  I think having multiple Proxy Subclasses is smelly
> and may well cause big problems.   A big problem regardless, will be the
> administration of capabilities.  Another question is what does it mean
> to pass a surrogate to another space?   All arguments to a msgSend
> should transform to the appropriate Surrogate (or direct pointer).  The
> return should also map.
> 

Hey, making it OS-like sounds good to me :)  It's a lot of work, though.
 I think you'd want some form of internal email and/or instant
messaging.  Also, you probably want to give each user a private "file"
space to store objects in.  Probably you want to make Squeak checkpoint
somehow, perhaps by doing a periodic snapshot, or perhaps by having a
background checkpointing-thread like in EROS and many other systems. 
Also, you probably want to give each user a *public* space, so they can
publish objects and messages and whatever.  And maybe you want these
object-spaces to be hierarchical, like a file system.


Anyway, I could well be missing something, but I don't see any
particular hindrances in making a secure multi-user Squeak system.  It's
mostly just a lot of mini-applications you'd have to write before the
thing started really looking like an OS.  (But what a cool OS you could
write, where all users have a graphics device that is in the same
ObjectMemory as yours, and where email is done through message sends!)


Lex