[Squeak-e] Comments on Anthony's "...Shared Smalltalk"

[Withers, Robert]

> -----Original Message-----
> From: Anthony Hannan [mailto:ajh18 at cornell.edu]


> "Mark S. Miller" <markm at caplet.com> wrote:
> > (The above argument is also bit of a preview of my upcoming 
> "What's Wrong 
> > with Dynamic Scoping?")
> 
> I agree dynamic scoping is bad (my "smart" capabilities would have
> relied on it).  The only tricky thing is how to handle exceptions.

Guys, I don't agree that dynamic scoping is bad, it just may not be secure
in it's current form.  Colin's recent comments drives this point home.  If
the environment isn't open from top to bottom to our investigation and
modification, then it isn't going to be Smalltalk.  This is a critical
feature to retain.

Traits, continuations and my eventual sending redirectors are other examples
where either dynamic scoping or system openness are crucial to allow us the
facility.  The reason I include both dynamic scoping and system openness, is
that the openness of Squeak _currently_ depends on dynamic scoping.  We
shouldn't lose this as we shift towards more security; in fact we should
only extend squeak to start supporting security, and keep it backwards
compatible.  

We can start this process by looking at providing more vm support for
evental sending, finishing CapTP, and by migrating Lex's Islands work to
3.5.  Thus I think the short-term (couple of months) goal should be
supporting security level 2 of Mark's original proposal.
 

> Your right, I'm giving too much authority to Kernel creators. 
>  So instead
> I propose that once a creator "releases" his class he can no longer
> change it.  If he wants to make revisions he has to create a new
> subclass.  Others may decide to use his new subclass or not.  They may
> migrate existing instances to the new class and/or use the 
> new class for
> new instances.

I don't like this restriction.  Classes and code should be able to evolve.
Now if an 'Island' has classes bound into it, those classes shouldn't
change, unless the right capabilities to change them are held.

I think the argument Mark is making is that there isn't a central authority.
In fact, there is no third party security sever or third party interface
respository.  I do think that we could specify the protocols for a base
library, but that's really what the ANSI spec is about.  There may be some
library specification additions for supporting security/eventual sends.

> MarkM wrote:

> > Same problem then. I think these can't be automatically 
> replicated, because 
> > there is no one authority everyone would mutually trust. At 
> least I hope there 
> > won't be. A world in which there's some one authority 
> everyone is willing to 
> > make themselves fully vulnerable to is a world ripe for 
> dictatorship.
> 
> Yes, like above I will change this so no one has authority once the
> pool is "released".  However, I will still allow the creator 
> to add new
> classes to a pool.  This is where he could add his new 
> subclass versions. 
> Adding to a pool is benign.

Again, I think that with the right capability, these things could be changed
'locally'.  The issue is that there isn't a global authority.
 


I am encouraged that although this list is turning out to be on the quiet
side, there is much interest in what we are considering.  The fact that we
are doing so in a thoughtful way is to our advantage.   

I will be a little more active this weekend, now that the work week is
winding down.  I want to implement RemoteHandlers (virtual circuits with
remote objects) and the objectMap.  

The other dimension, that I have been doing a little work with this past
week, is cleaning up the EventualReferences.   I am hanging out on the IRC
channel #squeak-e and will be available there to guide anyone wanting to
dive into this very intriguing mechanism.  Look at ReferenceContext (the
eventual reference), and RedirectionManager (the underlying redirection
mechanism).  If you build a redirection vm, make sure you doit to
'RedirectionManager enable'.  I will update the SqueakElib package this
evening.

cheers,
rob