Just throwing stuff against the wall to see what sticks, so to speak ...
There has been some talk about trying to get more developers involved with Croquet by introducing a new scripting language which has a larger following than Smalltalk. I'm not sure that is the only approach, just witness SecondLife's scripting language. I am more interested in just how a new scripting language would relate to Croquet's collaboration architecture. Is it primarily for use inside the replicated island, outside in the local UI, or both? Or maybe it could piggyback on the Croquet router, watching the stream of router messages and generating its own directly to the router. How does the user interact with the scripting language when building, executing, and debugging scripts? What is the environment for each of these activities? In my view, the exact control structures and syntax for a computer language is really a secondary concern. In order for a scripting language to be valuable it must have clean, easy access to the objects in Croquet. Is this limited to the objects within the replicated island? How does this language gain this access? Is a new API for Croquet objects needed which exposes explicit properties for explicitly exposed Croquet objects? |
Local UI object scripting via simple (non-Squeak) language would be terrific.
Besides the obvious advantages of "starting small" with local modifications (non-replicated even) it would be a great way to get new people going. I'm imagining how it would be a lot nicer for new users to use 3 simple scripting commands to (for instance) create a sphere/object, color it blue, and double the radius/size. Knowing & understanding those 3 commands vs. the amount of Squeak/Croquet experience required to do the same could certainly lower the entry level. Besides, it's not necessary to pick an established scripting language to out-do LSL right from the get-go. "Make sphere named Jimmy; Make Jimmy blue; Make Jimmy bigger". Have it be really basic, and if you want more power you learn Squeak. -Matt Senne On 9/17/07, David Faught <[hidden email]> wrote: > Just throwing stuff against the wall to see what sticks, so to speak ... > > There has been some talk about trying to get more developers involved with > Croquet by introducing a new scripting language which has a larger following > than Smalltalk. I'm not sure that is the only approach, just witness > SecondLife's scripting language. I am more interested in just how a new > scripting language would relate to Croquet's collaboration architecture. Is it > primarily for use inside the replicated island, outside in the local UI, or > both? Or maybe it could piggyback on the Croquet router, watching the stream > of router messages and generating its own directly to the router. How does the > user interact with the scripting language when building, executing, and > debugging scripts? What is the environment for each of these activities? > > In my view, the exact control structures and syntax for a computer language is > really a secondary concern. In order for a scripting language to be valuable > it must have clean, easy access to the objects in Croquet. Is this limited to > the objects within the replicated island? How does this language gain this > access? Is a new API for Croquet objects needed which exposes explicit > properties for explicitly exposed Croquet objects? > |
In reply to this post by David Faught
On 9/17/07, David Faught <[hidden email]> wrote: Just throwing stuff against the wall to see what sticks, so to speak ... This is the approach I'm taking with the Croquet implementation of the BOPSpace platform which uses a time-based, message passing facility called GVScript that can be easily implemented in many dynamic OO languages - Second Life and Squeak screencasts are available. With GVScript a programmer could write a script in her favorite language, save it in JSON format and deliver it to different rendering/execution environments. I'm currently deploying with an enhanced Wonderland for several reasons including:
Laurence How does the |
On 9/18/07, Laurence Rozier <[hidden email]> wrote:
> > > On 9/17/07, David Faught <[hidden email]> wrote: > > Just throwing stuff against the wall to see what sticks, so to speak ... > > > > There has been some talk about trying to get more developers involved with > > Croquet by introducing a new scripting language which has a larger > following > > than Smalltalk. I'm not sure that is the only approach, just witness > > SecondLife's scripting language. I am more interested in just how a new > > scripting language would relate to Croquet's collaboration architecture. > Is it > > primarily for use inside the replicated island, outside in the local UI, > or > > both? Or maybe it could piggyback on the Croquet router, watching the > stream > > of router messages and generating its own directly to the router. > > This is the approach I'm taking with the Croquet implementation of the > BOPSpace platform which uses a time-based, message passing facility called > GVScript that can be easily implemented in many dynamic OO languages - > Second Life and Squeak screencasts are available. With GVScript a programmer > could write a script in her favorite language, save it in JSON format and > deliver it to different rendering/execution environments. I'm currently > deploying with an enhanced Wonderland for several reasons including: > > I believe that there's a need for an easy-to-deploy solution that will run > on lower end hw > I've been working in an enhanced Wonderland for a good 5 years so it's much > easier to put the pieces back together when things go wrong. > Wonderland got a number of things right in terms of approachability > I was planning(and still expect) to have the specs and full source code > ready by the end of this week. After that I planned to clean up the > Wonderland implementation, move it to early beta and start soliciting > collaborators so this email is a little premature, but if anyone sees this > as a positive direction let me know. This sounds like an interesting approach and also sounds like you have made a lot of progress with it. Looking forward to trying it out. |
Thinking a little more about this, I can see reasons for a scripting
language to talk to visible objects inside the replicated island both through the router and directly with the script itself being replicated. In the first case, one client (maybe through the harness) can generate messages that get passed around to all participants through the message replication process. This could potentially be lots of messages depending on what the script is doing. In a script loop runaway situation, the router would probably be overwhelmed. Because of network delays this might be slow, again depending on what the script is doing. In the second case, the script itself would be in the island and would interact directly with the island-contained objects through replicated computation, perhaps triggered by an outside message. This would be much less network and router traffic. In a script loop runaway situation, every partitipant's local island copy would possibly lock up their CPU. Actual (properly working) script execution would be quite fast. There are certain advantages to each approach. I'm not sure that I see any particular reason to script the local non-replicated UI outside of what is already provided by Tweak though. And then there is the whole idea of a replicated UI like Brie ... Dave On 9/18/07, David Faught <[hidden email]> wrote: > On 9/18/07, Laurence Rozier <[hidden email]> wrote: > > > > > > On 9/17/07, David Faught <[hidden email]> wrote: > > > Just throwing stuff against the wall to see what sticks, so to speak ... > > > > > > There has been some talk about trying to get more developers involved with > > > Croquet by introducing a new scripting language which has a larger > > following > > > than Smalltalk. I'm not sure that is the only approach, just witness > > > SecondLife's scripting language. I am more interested in just how a new > > > scripting language would relate to Croquet's collaboration architecture. > > Is it > > > primarily for use inside the replicated island, outside in the local UI, > > or > > > both? Or maybe it could piggyback on the Croquet router, watching the > > stream > > > of router messages and generating its own directly to the router. > > > > This is the approach I'm taking with the Croquet implementation of the > > BOPSpace platform which uses a time-based, message passing facility called > > GVScript that can be easily implemented in many dynamic OO languages - > > Second Life and Squeak screencasts are available. With GVScript a programmer > > could write a script in her favorite language, save it in JSON format and > > deliver it to different rendering/execution environments. I'm currently > > deploying with an enhanced Wonderland for several reasons including: > > > > I believe that there's a need for an easy-to-deploy solution that will run > > on lower end hw > > I've been working in an enhanced Wonderland for a good 5 years so it's much > > easier to put the pieces back together when things go wrong. > > Wonderland got a number of things right in terms of approachability > > I was planning(and still expect) to have the specs and full source code > > ready by the end of this week. After that I planned to clean up the > > Wonderland implementation, move it to early beta and start soliciting > > collaborators so this email is a little premature, but if anyone sees this > > as a positive direction let me know. > > This sounds like an interesting approach and also sounds like you have > made a lot of progress with it. Looking forward to trying it out. > |
Free forum by Nabble | Edit this page |