Lex Spoon wrote:

Thanks for your thoughtful response. 

> It sounds like you could also use a capabilities model, if you wanted.
> The way you'd do it is to allow a sphere to be referenced from outside,
> but only if someone who has access to the sphere has passed out the
> reference.  For example, BAZ could pass to FOO a reference to BAT, and
> then FOO could call walk into the BAT as well.

That is, infact, one of the primary mechanisms of Sphere! =) 

It is bad policy to reveal your internal structure, so you don't tell
anyone about baz or bat for any reason ever. 

HOWEVER, A rather conventional filesystem would be implemented by
passing genenral requests on to the appropriate sub-sphere. 

An incoming filesystem request would be analyzed and then sent to the
appropriate subsystems. 

One of the few exceptions to this transperancy is the device driver
system, A driver sphere would publish interfaces almost directly to a
registry maintained by the primary server.

> BAZ doesn't want to give out direct access to BAZOINKA, so it created
> BAT on a request from FOO that gives just a little of the power of
> BAZOINKA.  Maybe BAZOINKA is a directory and BAT is a file in that
> directory.

BAZ would hide what needed to be hidden... These would include
interfaces necessary to BAT's peers but not to outside users. --
Complexity is treated as an arch vilian in this system...

> I hope you stick with your efforts on system and language design.  It 
> sounds like fun, and something really great could come out of it!  Once 
> you've got your ideas down, though, be sure and check with works by 
> other designers.  Have you looked at the two History of Programming 
> Languages volumes published by ACM? 

No, Thanx for the reff! 

-- 
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/