>On 7/29/2010 5:08 AM, David Faught wrote:
>> On 7/29/2010, Andreas Raab wrote:
>>> 1) Create a local proxy for the replicated object and have it control
>>> the replicated target. This has the advantage that you don't need to
>>> replicate the script but the disadvantage that the script is
>>> disassociated from the object and won't persist if the local user drops out.
>>>
>>> 2) Replicate the script into the island and run it there. This is
>>> obviously more in line with the ideas of Croquet but the thought of all
>>> the things that could go wrong led me to never go down this path.

>> Option number 2 is what I used in the MockTurtle demo.  This project
>> only used a code editor in the local proxy instead of tile scripting,
>> and when the edit was accepted the script text was first locally
>> syntax checked and then sent to the associated replicated object.
>> This was actually lots of fun, but needed to have some "future"s
>> handcoded in the edited source as I recall.  Some keystrokes in the
>> harness directed to the target replicated object caused editing or
>> script execution to start.  In my isolated testing, this worked just
>> fine.

>How did you deal with persistence and replication? One of the main
>issues with the approach is having to include compiled methods in the
>island snapshot. Or did you have an explicit "code sync" step before
>replicating the island contents?

I guess that I cheated by ignoring persistence and took a very simple
minded approach.  By choice there were no compiled methods.  And yes,
that limited its usefulness, but it was still lots of fun.  The
locally edited code was sent to the target replicated object as a text
string and the replicated object saved it in a single instance
variable, so each replicated object could have exactly one script.
When the target object was triggered to run the code, it essentially
did a "doIt" on the string.  There wasn't anything more to it than
that.

Cheers,
Dave