Smalltalk
› Squeak
› Croquet
›
Croquet - Dev
Island Classes
Locked
 
|
Regarding the Island Classes item in the Croquet Roadmap at
http://croquetconsortium.org/index.php/Road_Map#Island_Classes I don't think that I quite understand how this would work exactly. If the classes exist in the replicated island, then they get replicated, right? Which means that they are then present on the participant machines, and it seems that this would require namespaces to really separate those classes from the rest that are already on the participant machines. I completely understand the part about wanting a collaborative code development environment and have played with that a little myself. The MockTurtle package on the Hedgehog PublicContribs repository seems to work just fine with the SDK 1.0 even though it predates it a little. The VRML package from that same repository must also be loaded to try it out. For this iteration of the MockTurtle package, the approach taken was to bring up a code panel for editing in the local user's non-replicated Tweak world, then when the script/code is accepted, it is precompiled in that local environment to eliminate syntax errors, and when it compiles clean, the text string containing the code is sent to the replicated turtle object as the contents of an instance variable. There can be many turtle instances in the replicated space, each with its own script text string. When a turtle's script is executed, it is done in the form of a DoIt, which does temporarily get compiled into the turtle's class, I believe, and this temporary existence in the class might be a source of conflict between the different turtles. This approach has the advantage that it minimizes the replication interaction of editing keystrokes while still allowing collaboration in developing replicated scripts, either by taking turns for a single turtle, or by having each participant script their own turtle(s), or some combination of these. The disadvantages are that the script cannot be directly viewed in the replicated space, and that there is (currently) only one script per turtle instance. Also, these scripts are not saved as methods in the class, other than temporarily as I noted above. The scope of the collaborative editing was purposely limited in this fashion, rather than just bringing up a full code browser, in order to progressively step into any problems that might arise, as well as to keep the interface simple. I know that others have worked on the idea of collaborative code development in Croquet, I just wanted to point out this particular approach to possibly provide some discussion points. Dave |
|
|
On May 21, 2007, at 15:17 , David Faught wrote: > Regarding the Island Classes item in the Croquet Roadmap at > http://croquetconsortium.org/index.php/Road_Map#Island_Classes > I don't think that I quite understand how this would work exactly. If > the classes exist in the replicated island, then they get replicated, > right? Which means that they are then present on the participant > machines, and it seems that this would require namespaces to really > separate those classes from the rest that are already on the > participant machines. Actually you would not have access to the "rest". No free access to any globals, in fact. An island would be truly self-contained. - Bert - |
|
|
On 5/21/07, Bert Freudenberg <[hidden email]> wrote:
> > On May 21, 2007, at 15:17 , David Faught wrote: > > > Regarding the Island Classes item in the Croquet Roadmap at > > http://croquetconsortium.org/index.php/Road_Map#Island_Classes > > I don't think that I quite understand how this would work exactly. If > > the classes exist in the replicated island, then they get replicated, > > right? Which means that they are then present on the participant > > machines, and it seems that this would require namespaces to really > > separate those classes from the rest that are already on the > > participant machines. > > Actually you would not have access to the "rest". No free access to > any globals, in fact. An island would be truly self-contained. So then all the classes that the participant has would also be present in the island. Silly me, that is true anyway or replicated computation wouldn't work! So the real question is one of replication of code CHANGES? Dave |
|
|
On May 21, 2007, at 15:37 , David Faught wrote: > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> On May 21, 2007, at 15:17 , David Faught wrote: >> >> > Regarding the Island Classes item in the Croquet Roadmap at >> > http://croquetconsortium.org/index.php/Road_Map#Island_Classes >> > I don't think that I quite understand how this would work >> exactly. If >> > the classes exist in the replicated island, then they get >> replicated, >> > right? Which means that they are then present on the participant >> > machines, and it seems that this would require namespaces to really >> > separate those classes from the rest that are already on the >> > participant machines. >> >> Actually you would not have access to the "rest". No free access to >> any globals, in fact. An island would be truly self-contained. > > So then all the classes that the participant has would also be present > in the island. Silly me, that is true anyway or replicated > computation wouldn't work! So the real question is one of replication > of code CHANGES? Classes and methods are objects like everything else so they would simply be replicated like everything else is. - Bert - |
|
|
On 5/21/07, Bert Freudenberg <[hidden email]> wrote:
> > On May 21, 2007, at 15:37 , David Faught wrote: > > > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: > >> > >> On May 21, 2007, at 15:17 , David Faught wrote: > >> > >> > Regarding the Island Classes item in the Croquet Roadmap at > >> > http://croquetconsortium.org/index.php/Road_Map#Island_Classes > >> > I don't think that I quite understand how this would work > >> exactly. If > >> > the classes exist in the replicated island, then they get > >> replicated, > >> > right? Which means that they are then present on the participant > >> > machines, and it seems that this would require namespaces to really > >> > separate those classes from the rest that are already on the > >> > participant machines. > >> > >> Actually you would not have access to the "rest". No free access to > >> any globals, in fact. An island would be truly self-contained. > > > > So then all the classes that the participant has would also be present > > in the island. Silly me, that is true anyway or replicated > > computation wouldn't work! So the real question is one of replication > > of code CHANGES? > > Classes and methods are objects like everything else so they would > simply be replicated like everything else is. Then I'm still not sure exactly what this item is about. Is it just the idea of introducing a code browser into the replicated space? |
|
|
Currently, users need identical code in their image for replication to
work properly. This is extremely restrictive in what can be shared dynamically. Placing classes into an Island allows both that users can collaborate on code design and allows dynamic late-bound code synchronization when you join an Island. This is code that is specific to just this single Island. David David Faught wrote: > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> On May 21, 2007, at 15:37 , David Faught wrote: >> >> > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> >> >> On May 21, 2007, at 15:17 , David Faught wrote: >> >> >> >> > Regarding the Island Classes item in the Croquet Roadmap at >> >> > http://croquetconsortium.org/index.php/Road_Map#Island_Classes >> >> > I don't think that I quite understand how this would work >> >> exactly. If >> >> > the classes exist in the replicated island, then they get >> >> replicated, >> >> > right? Which means that they are then present on the participant >> >> > machines, and it seems that this would require namespaces to really >> >> > separate those classes from the rest that are already on the >> >> > participant machines. >> >> >> >> Actually you would not have access to the "rest". No free access to >> >> any globals, in fact. An island would be truly self-contained. >> > >> > So then all the classes that the participant has would also be present >> > in the island. Silly me, that is true anyway or replicated >> > computation wouldn't work! So the real question is one of replication >> > of code CHANGES? >> >> Classes and methods are objects like everything else so they would >> simply be replicated like everything else is. > > Then I'm still not sure exactly what this item is about. Is it just > the idea of introducing a code browser into the replicated space? |
|
|
In reply to this post by David Faught
The idea is that some islands will have different capabilities and
will need additional software. Right now we it is very difficult to connect two participants because there is a good chance that are not running the same version of the code. At least that is a problem for us since we are constantly adding new classes or changing existing ones. So we have to sync up via Monticello or pass around a copy of an image to avoid crashing when we attempt to connect. -Peter On May 21, 2007, at 9:04 AM, David Faught wrote: > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> On May 21, 2007, at 15:37 , David Faught wrote: >> >> > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> >> >> On May 21, 2007, at 15:17 , David Faught wrote: >> >> >> >> > Regarding the Island Classes item in the Croquet Roadmap at >> >> > http://croquetconsortium.org/index.php/Road_Map#Island_Classes >> >> > I don't think that I quite understand how this would work >> >> exactly. If >> >> > the classes exist in the replicated island, then they get >> >> replicated, >> >> > right? Which means that they are then present on the >> participant >> >> > machines, and it seems that this would require namespaces to >> really >> >> > separate those classes from the rest that are already on the >> >> > participant machines. >> >> >> >> Actually you would not have access to the "rest". No free >> access to >> >> any globals, in fact. An island would be truly self-contained. >> > >> > So then all the classes that the participant has would also be >> present >> > in the island. Silly me, that is true anyway or replicated >> > computation wouldn't work! So the real question is one of >> replication >> > of code CHANGES? >> >> Classes and methods are objects like everything else so they would >> simply be replicated like everything else is. > > Then I'm still not sure exactly what this item is about. Is it just > the idea of introducing a code browser into the replicated space? |
|
|
In reply to this post by David Faught
On May 21, 2007, at 16:04 , David Faught wrote: > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> On May 21, 2007, at 15:37 , David Faught wrote: >> >> > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> >> >> >> On May 21, 2007, at 15:17 , David Faught wrote: >> >> >> >> > Regarding the Island Classes item in the Croquet Roadmap at >> >> > http://croquetconsortium.org/index.php/Road_Map#Island_Classes >> >> > I don't think that I quite understand how this would work >> >> exactly. If >> >> > the classes exist in the replicated island, then they get >> >> replicated, >> >> > right? Which means that they are then present on the >> participant >> >> > machines, and it seems that this would require namespaces to >> really >> >> > separate those classes from the rest that are already on the >> >> > participant machines. >> >> >> >> Actually you would not have access to the "rest". No free >> access to >> >> any globals, in fact. An island would be truly self-contained. >> > >> > So then all the classes that the participant has would also be >> present >> > in the island. Silly me, that is true anyway or replicated >> > computation wouldn't work! So the real question is one of >> replication >> > of code CHANGES? >> >> Classes and methods are objects like everything else so they would >> simply be replicated like everything else is. > > Then I'm still not sure exactly what this item is about. Is it just > the idea of introducing a code browser into the replicated space? Well, it has to be implemented and debugged and made work ;) For now this replication of classes is only a dream. - Bert - |
|
|
On 5/21/07, Bert Freudenberg <[hidden email]> wrote:
> Well, it has to be implemented and debugged and made work ;) For now > this replication of classes is only a dream. Okay, so this deals with both a means of making changes to classes and methods as well as implementing the replication of those changes. Back to my MockTurtle example ... one way this could be done is with the current Tweak code browser in the user-local context sending accepted changes to a compile process in the replicated island and thereby the participants. You would want to compile the accepted changes into a class instead of just putting it in an instance variable as MockTurtle does. An alternate approach would be to put the actual code browser itself into the replicated space, which would accomplish a similar thing but with more overhead (replicated keystrokes) and more visibility. Of course having both alternatives would be nice, but is one more important? How would you envision this working? |
|
|
What about this as a question to answer. The standard fish example that comes with the current Croquet SDK, containing the fish as well as the logic that changes the current user's avatar into a fish when he enters. If my image or SDK had no prior knowledge of this island (or it was something that someone outside of the standard distribution channels had created), how can I join the island and have not only the objects and assets downloaded to my machine, but also the classes and logic as well? Considering that TeaTime is defined as the replication of computation, this is probably very important.
Also consider what happens if I already have information about one Fish Island and want to connect to a second one that has had some customizations. Connecting to that second island will require that I download updated classes just for that island, and furthermore that those updates are not used when connecting to the first island, which has no knowledge of those changes. There was a post here earlier about an early version of Jabberwocky that was recently posted. The comment was made that one should not connect to any public island after adding the Jabberwocky updates as the updated classes would be incompatible with the shared islands available. If the code were bound to the island though, either client could connect to either type of island, although non-Jabberwocky clients may experience a degraded UI (non-replicated) experience. On 5/21/07, David Faught <[hidden email]> wrote: On 5/21/07, Bert Freudenberg <[hidden email]> wrote: |
|
|
The idea of Not carrying forward any classes replicated from an island
when leaving to go to the next island especially points out another thing that keeps nagging me during this whole discussion, that of security and integrity. What is to stop someone from misusing, or mistakenly using, a replicated class mechanism to spread mischievous code, i.e. "Don't go to Death Virus Island, I've heard bad things about it." I'm as much in favor of honesty and good will as the next person, but you've got to admit that replicating code provides a quick way to spread bad things too. Dave On 5/21/07, Erik Anderson <[hidden email]> wrote: > What about this as a question to answer. The standard fish example that > comes with the current Croquet SDK, containing the fish as well as the logic > that changes the current user's avatar into a fish when he enters. If my > image or SDK had no prior knowledge of this island (or it was something that > someone outside of the standard distribution channels had created), how can > I join the island and have not only the objects and assets downloaded to my > machine, but also the classes and logic as well? Considering that TeaTime > is defined as the replication of computation, this is probably very > important. > > Also consider what happens if I already have information about one Fish > Island and want to connect to a second one that has had some customizations. > Connecting to that second island will require that I download updated > classes just for that island, and furthermore that those updates are not > used when connecting to the first island, which has no knowledge of those > changes. > > There was a post here earlier about an early version of Jabberwocky that was > recently posted. The comment was made that one should not connect to any > public island after adding the Jabberwocky updates as the updated classes > would be incompatible with the shared islands available. If the code were > bound to the island though, either client could connect to either type of > island, although non-Jabberwocky clients may experience a degraded UI > (non-replicated) experience. > > > On 5/21/07, David Faught <[hidden email]> wrote: > > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: > > > Well, it has to be implemented and debugged and made work ;) For now > > > this replication of classes is only a dream. > > > > Okay, so this deals with both a means of making changes to classes and > > methods as well as implementing the replication of those changes. > > > > Back to my MockTurtle example ... one way this could be done is with > > the current Tweak code browser in the user-local context sending > > accepted changes to a compile process in the replicated island and > > thereby the participants. You would want to compile the accepted > > changes into a class instead of just putting it in an instance > > variable as MockTurtle does. > > > > An alternate approach would be to put the actual code browser itself > > into the replicated space, which would accomplish a similar thing but > > with more overhead (replicated keystrokes) and more visibility. > > > > Of course having both alternatives would be nice, but is one more > > important? How would you envision this working? > > > > |
|
|
That's why islands need to be isolated, to prevent bad code in one
island affecting other islands. Even if the code in one island goes berzerk it should be safe to view it, for example. You can just close the portal and that's it. - Bert - On May 21, 2007, at 20:00 , David Faught wrote: > The idea of Not carrying forward any classes replicated from an island > when leaving to go to the next island especially points out another > thing that keeps nagging me during this whole discussion, that of > security and integrity. What is to stop someone from misusing, or > mistakenly using, a replicated class mechanism to spread mischievous > code, i.e. "Don't go to Death Virus Island, I've heard bad things > about it." > > I'm as much in favor of honesty and good will as the next person, but > you've got to admit that replicating code provides a quick way to > spread bad things too. > > Dave > > On 5/21/07, Erik Anderson <[hidden email]> wrote: >> What about this as a question to answer. The standard fish >> example that >> comes with the current Croquet SDK, containing the fish as well as >> the logic >> that changes the current user's avatar into a fish when he >> enters. If my >> image or SDK had no prior knowledge of this island (or it was >> something that >> someone outside of the standard distribution channels had >> created), how can >> I join the island and have not only the objects and assets >> downloaded to my >> machine, but also the classes and logic as well? Considering that >> TeaTime >> is defined as the replication of computation, this is probably very >> important. >> >> Also consider what happens if I already have information about one >> Fish >> Island and want to connect to a second one that has had some >> customizations. >> Connecting to that second island will require that I download >> updated >> classes just for that island, and furthermore that those updates >> are not >> used when connecting to the first island, which has no knowledge >> of those >> changes. >> >> There was a post here earlier about an early version of >> Jabberwocky that was >> recently posted. The comment was made that one should not connect >> to any >> public island after adding the Jabberwocky updates as the updated >> classes >> would be incompatible with the shared islands available. If the >> code were >> bound to the island though, either client could connect to either >> type of >> island, although non-Jabberwocky clients may experience a degraded UI >> (non-replicated) experience. >> >> >> On 5/21/07, David Faught <[hidden email]> wrote: >> > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: >> > > Well, it has to be implemented and debugged and made work ;) >> For now >> > > this replication of classes is only a dream. >> > >> > Okay, so this deals with both a means of making changes to >> classes and >> > methods as well as implementing the replication of those changes. >> > >> > Back to my MockTurtle example ... one way this could be done is >> with >> > the current Tweak code browser in the user-local context sending >> > accepted changes to a compile process in the replicated island and >> > thereby the participants. You would want to compile the accepted >> > changes into a class instead of just putting it in an instance >> > variable as MockTurtle does. >> > >> > An alternate approach would be to put the actual code browser >> itself >> > into the replicated space, which would accomplish a similar >> thing but >> > with more overhead (replicated keystrokes) and more visibility. >> > >> > Of course having both alternatives would be nice, but is one more >> > important? How would you envision this working? >> > >> >> |
|
|
One of the biggest problems that SecondLife has is one of controlling
"grey goo", that is intentionally malicious code intent on spreading
itself throughout the grid, usually crashing "sim" world servers in the process. There's been no real thought on this in Croquet (yet) that I can see, but mostly because the system isn't advanced enough to support mobile agents (although I wouldn't be surprised to see someone exploiting the current classes to come up with something malicious purely through object references).
We definitely need to be able to isolate custom code, preventing it from spreading to islands that have similar classes. The only way that mobile agents should be able to show up on different islands is if they somehow managed to open a portal and send themselves through. We also need to consider security as well. There are an awful lot of "shoulds" in the wiki, it actually does read as though the firewall between the replicated island and the non-replicated client could be breached. Beyond caring whether opening a portal to an island causes the viewer to halt, would objects have access to the user's local system? To arbitrary network ports? On 5/21/07, Bert Freudenberg <[hidden email]> wrote: That's why islands need to be isolated, to prevent bad code in one |
|
|
Actually quite a bit of thought has been given to security in
Croquet, but no real system is in place yet. Part of the inspiration for Islands were VATs in E, and capability-based security in general is what we're after (the router for example uses that already). So no "firewall" but simply capabilities - if you do not have a reference to an object, you cannot possibly send it some "malicious" message. - Bert - On May 21, 2007, at 20:15 , Erik Anderson wrote: > One of the biggest problems that SecondLife has is one of > controlling "grey goo", that is intentionally malicious code intent > on spreading itself throughout the grid, usually crashing "sim" > world servers in the process. There's been no real thought on this > in Croquet (yet) that I can see, but mostly because the system > isn't advanced enough to support mobile agents (although I wouldn't > be surprised to see someone exploiting the current classes to come > up with something malicious purely through object references). > > We definitely need to be able to isolate custom code, preventing it > from spreading to islands that have similar classes. The only way > that mobile agents should be able to show up on different islands > is if they somehow managed to open a portal and send themselves > through. > > We also need to consider security as well. There are an awful lot > of "shoulds" in the wiki, it actually does read as though the > firewall between the replicated island and the non-replicated > client could be breached. Beyond caring whether opening a portal > to an island causes the viewer to halt, would objects have access > to the user's local system? To arbitrary network ports? > > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: That's > why islands need to be isolated, to prevent bad code in one > island affecting other islands. Even if the code in one island goes > berzerk it should be safe to view it, for example. You can just close > the portal and that's it. > > - Bert - > > On May 21, 2007, at 20:00 , David Faught wrote: > > > The idea of Not carrying forward any classes replicated from an > island > > when leaving to go to the next island especially points out another > > thing that keeps nagging me during this whole discussion, that of > > security and integrity. What is to stop someone from misusing, or > > mistakenly using, a replicated class mechanism to spread mischievous > > code, i.e. "Don't go to Death Virus Island, I've heard bad things > > about it." > > > > I'm as much in favor of honesty and good will as the next person, > but > > you've got to admit that replicating code provides a quick way to > > spread bad things too. > > > > Dave > > > > On 5/21/07, Erik Anderson <[hidden email]> wrote: > >> What about this as a question to answer. The standard fish > >> example that > >> comes with the current Croquet SDK, containing the fish as well as > >> the logic > >> that changes the current user's avatar into a fish when he > >> enters. If my > >> image or SDK had no prior knowledge of this island (or it was > >> something that > >> someone outside of the standard distribution channels had > >> created), how can > >> I join the island and have not only the objects and assets > >> downloaded to my > >> machine, but also the classes and logic as well? Considering that > >> TeaTime > >> is defined as the replication of computation, this is probably very > >> important. > >> > >> Also consider what happens if I already have information about one > >> Fish > >> Island and want to connect to a second one that has had some > >> customizations. > >> Connecting to that second island will require that I download > >> updated > >> classes just for that island, and furthermore that those updates > >> are not > >> used when connecting to the first island, which has no knowledge > >> of those > >> changes. > >> > >> There was a post here earlier about an early version of > >> Jabberwocky that was > >> recently posted. The comment was made that one should not connect > >> to any > >> public island after adding the Jabberwocky updates as the updated > >> classes > >> would be incompatible with the shared islands available. If the > >> code were > >> bound to the island though, either client could connect to either > >> type of > >> island, although non-Jabberwocky clients may experience a > degraded UI > >> (non-replicated) experience. > >> > >> > >> On 5/21/07, David Faught < [hidden email]> wrote: > >> > On 5/21/07, Bert Freudenberg <[hidden email]> wrote: > >> > > Well, it has to be implemented and debugged and made work ;) > >> For now > >> > > this replication of classes is only a dream. > >> > > >> > Okay, so this deals with both a means of making changes to > >> classes and > >> > methods as well as implementing the replication of those changes. > >> > > >> > Back to my MockTurtle example ... one way this could be done is > >> with > >> > the current Tweak code browser in the user-local context sending > >> > accepted changes to a compile process in the replicated island > and > >> > thereby the participants. You would want to compile the accepted > >> > changes into a class instead of just putting it in an instance > >> > variable as MockTurtle does. > >> > > >> > An alternate approach would be to put the actual code browser > >> itself > >> > into the replicated space, which would accomplish a similar > >> thing but > >> > with more overhead (replicated keystrokes) and more visibility. > >> > > >> > Of course having both alternatives would be nice, but is one more > >> > important? How would you envision this working? > >> > > >> > >> > > > |
«
Return to Croquet - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |