On 2004, Jul 24, , at 19:05, Mark Miller wrote:
[...] Several of us were distracted, in a major way, this week. More about that soon...
We were distracted by an invitation-only workshop, held at HP Labs, focused on exploring future possibilities for Croquet. http://chess.eecs.berkeley.edu/croquet/ is a start on a website resulting from this workshop. The workshop was organized by Rick McGeer and attended by about 30 people, including * three of the main Croquet architects (David Smith, David Reed, and Andreas Raab), * several other Croquet-ers (Mark McCahill, Julian Lombardi) * and Squeakers (Dan Ingalls, Ted Keahler, Lex Spoon, Anthony Hannan, Ian Piumarta, Scott Wallace), * several members of the e-lang community (Chip Morningstar, Kevin Reid, Ka-Ping Yee, Marc Stiegler, Alan Karp, Tyler Close, Dean Tribble, and myself), * George Bosworth of Digitalk Smalltalk and .NET CLR fame, * Robert Adams of Intel and PlanetLab, * and Prof. Edward Lee of Berkeley. * (and probably some others I forgot)
The Electric Communities and e-lang perspectives were represented well, and played well with other perspectives that were presented. I think the lessons from our perspectives were taken to heart, and their relevance to the Croquet undertaking were clear. Actually, I think I'm way understating the case, but I'll wait to see what others have to say.
In any case, I think it's fair to say that we have consensus on using object-capability security as the underlying security mechanism, on top of which Croquet's security architecture should be built. And that we have consensus that "Threads are evil" -- that the conventional (shared memory multithreading & fine-grained locking) paradigm of concurrency is unworkable, and that instead, time should proceed according to a partial causal order among events, where each event is the deterministic execution of a sequential program to completion. (E and Croquet already have this perspective in common, but with some interesting differences.)
I have asked the Croquet architects to evaluate the suitability of the Kernel-E virtual machine definition as a proposed foundation on which Croquet should be reconstructed. They are currently evaluating it. If adopted, the plan would probably be to start by completing Dean's E-on-Squeak effort in the short term, and do a more direct implementation of Kernel-E on their virtual machine infrastructure in the long term.
At 04:05 PM 7/28/2004 Wednesday, Kevin Reid wrote:
(Note: the picture painted here doesn't yet cover the case where there are potentially multiple authoritative presences. I now think I like Dean's proposal for that better than Uni-Tea http://www.erights.org/talks/uni-tea/index.html .
I don't recall or never heard what Dean's proposal was.
In the Uni-Tea proposal, we map a Tea Party to an Unum, and make the replication of authoritative presences be a generalization of presence spread among vats. Dean suggests that, instead, we map a Tea Party to a virtual vat, and implement fault tolerant replicated vats. Then, at the vat level of abstraction, an individual Unum would still just have one authoritative presence, permanently tied to its virtual vat of origin. Rather than making the replication, consensus, and fault tolerance protocols be Unum design choices, we should make these choices when instantiating a fault-tolerant replicated vat. In Dean's proposal, it is especially clear that you only do fault tolerant replication among sites mutually trusted to try to run their replicas correctly, since that vat's private key would be replicated at all those sites.
Hello,
I am a long-time Squeaker, and have been following E and Squeak-E discussions and issues with interest. I am implementing what I consider to be a successor system to Squeak, titled "Slate" (see http://slate.tunes.org) which has been designed at least with expansion in mind to handle the issues that E does. I am currently working on the new concurrency mechanisms, and would like to know some details on your thoughts at this point for Squeak-like languages (after the debate over a year ago concerning the issues, which I did follow, I'm concerned with new developments).
Slate has essentially "zero baggage", and deals with a few issues mentioned previously about making Squeak capability secure (methods don't return "self" by default, and namespaces are well-structured and logical). I can elaborate in detail if necessary, but there is also a manual on our website which should give a good overview.
The virtual machine architecture is less well-documented being a newer development and just now reaching a stable design, but again it has very little baggage and no legacy overhead, so it is ripe for considering new ideas.
As a Squeak user, Croquet's project structure is relatively opaque, but of course the ideas are still interesting and lie within the field of projects that I want Slate to provide a better base for than Squeak currently does.
I don't have specific questions to start with, other than requesting some detailed overviews of how a Smalltalk-like architecture could be adapted to support E-like concurrency from the ground up (forgetting how any Smalltalk currently does it), and to start a discussion about specifics concerning Slate.
Thank you, Brian Rice
Mark Miller wrote:
On 2004, Jul 24, , at 19:05, Mark Miller wrote:
[...] Several of us were distracted, in a major way, this week. More about that soon...
We were distracted by an invitation-only workshop, held at HP Labs, focused on exploring future possibilities for Croquet. http://chess.eecs.berkeley.edu/croquet/ is a start on a website resulting from this workshop. The workshop was organized by Rick McGeer and attended by about 30 people, including
- three of the main Croquet architects (David Smith, David Reed, and Andreas Raab),
- several other Croquet-ers (Mark McCahill, Julian Lombardi)
- and Squeakers (Dan Ingalls, Ted Keahler, Lex Spoon, Anthony Hannan, Ian Piumarta, Scott Wallace),
- several members of the e-lang community (Chip Morningstar, Kevin Reid, Ka-Ping Yee, Marc Stiegler, Alan Karp, Tyler Close, Dean Tribble, and myself),
- George Bosworth of Digitalk Smalltalk and .NET CLR fame,
- Robert Adams of Intel and PlanetLab,
- and Prof. Edward Lee of Berkeley.
- (and probably some others I forgot)
The Electric Communities and e-lang perspectives were represented well, and played well with other perspectives that were presented. I think the lessons from our perspectives were taken to heart, and their relevance to the Croquet undertaking were clear. Actually, I think I'm way understating the case, but I'll wait to see what others have to say.
In any case, I think it's fair to say that we have consensus on using object-capability security as the underlying security mechanism, on top of which Croquet's security architecture should be built. And that we have consensus that "Threads are evil" -- that the conventional (shared memory multithreading & fine-grained locking) paradigm of concurrency is unworkable, and that instead, time should proceed according to a partial causal order among events, where each event is the deterministic execution of a sequential program to completion. (E and Croquet already have this perspective in common, but with some interesting differences.)
I have asked the Croquet architects to evaluate the suitability of the Kernel-E virtual machine definition as a proposed foundation on which Croquet should be reconstructed. They are currently evaluating it. If adopted, the plan would probably be to start by completing Dean's E-on-Squeak effort in the short term, and do a more direct implementation of Kernel-E on their virtual machine infrastructure in the long term.
At 04:05 PM 7/28/2004 Wednesday, Kevin Reid wrote:
(Note: the picture painted here doesn't yet cover the case where there are potentially multiple authoritative presences. I now think I like Dean's proposal for that better than Uni-Tea http://www.erights.org/talks/uni-tea/index.html .
I don't recall or never heard what Dean's proposal was.
In the Uni-Tea proposal, we map a Tea Party to an Unum, and make the replication of authoritative presences be a generalization of presence spread among vats. Dean suggests that, instead, we map a Tea Party to a virtual vat, and implement fault tolerant replicated vats. Then, at the vat level of abstraction, an individual Unum would still just have one authoritative presence, permanently tied to its virtual vat of origin. Rather than making the replication, consensus, and fault tolerance protocols be Unum design choices, we should make these choices when instantiating a fault-tolerant replicated vat. In Dean's proposal, it is especially clear that you only do fault tolerant replication among sites mutually trusted to try to run their replicas correctly, since that vat's private key would be replicated at all those sites.
squeak-e@lists.squeakfoundation.org
-
Brian T. Rice -
Mark Miller