[sugar] "Garden": A (currently hypothetical) Sugar library for sharing state between Activity participants

[Alan Kay]

Hi Folks --

The guts of the Croquet scheme are quite independent of Squeak, and 
were thought of as "a higher layer of TCP/IP". Also, the "Islands" 
were deliberately set up to be quite independent of what is inside 
the Island (which is a kind of abstraction for a 
virtual-machine-address-space that has objects). The idea here is 
that good things can happen if you really do "real messaging" and if 
you include time (pseudotime) specifically in your computing model.

As some of the folks on this list have realized, somewhat careful 
organization of a publish/subscribe facility can be the lingua franca 
for the Croquet coordination ideas.

As you can see from the website, Croquet was done to explore what I 
thought was a terrific PhD thesis (of Dave Reed ca. 1978 at MIT) but 
that never got implemented. Dave Reed is across the street at the 
Media Lab, is friendly and a fun guy to talk to, and is one of the 
best systems thinkers I've met over the years.

Cheers to all,

Alan

At 12:27 PM 11/27/2006, Ian Bicking wrote:
>Ken Ritchie wrote:
>>www.opencroquet.org (especially the TeaTime components)
>
>I just read the "Croquet System Overview" section of this: 
>http://www.opencroquet.org/Site%20PDFs/Croquet%20Programming%201.0B.pdf
>
>It was a very nice overview of the architecture of the system.  I 
>like the approach a lot; the description of the architecture makes 
>me want to bang out code *right now*, which is always a good 
>sign.  I'll try to resist actually doing so.
>
>Whether this should be reimplemented in Python or implemented in a 
>language-neutral way, I'm not sure.  I can kind of imagine the 
>Router being a service accessible over dbus, but I'm not really sure 
>what that would accomplish.  The dbus message format is also 
>possibly something to use (since Croquet messages, I assume, are 
>tied to Smalltalk).  But I don't know if that even matters -- 
>there's nothing here that really facilitates inter-language 
>communication, as it assumes that all Islands (aka objects) use 
>exactly the same code.
>
>I also wonder if there's room for more sloppy communication.  E.g., 
>situations where out-of-order message execution is preferable to 
>blocking.  If it damages the integrity of a simulation or 3D world, 
>it might be preferable to just block.  OTOH, I think there are other 
>kinds of collaboration where responsiveness may be more important 
>than complete integrity.  It perhaps depends in part on how good the 
>network connections are.  What will collaboration feel like over 
>several hops on a mesh?  What about over a satellite internet 
>connection?  I have no idea how this will effect the 
>experience.  And perhaps good message design can help with this 
>anyway.  For instance, if you are editing text you don't necessarily 
>want to send a message for every keystroke; the UI can batch things 
>up and resolve conflicts, even if the underlying objects are less 
>forgiving.  So maybe I'm imagining the problem.
>
>--
>Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
>_______________________________________________
>Sugar mailing list
>Sugar at laptop.org
>http://mailman.laptop.org/mailman/listinfo/sugar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/sugar/attachments/20061128/dd142869/attachment.html