Collaborative Logo in Croquet

> I am currently examining possible paths to implement a collaborative
> version of Logo (or rather (Star|Net)Logo) using Croquet. All those
> paths seem to result in one question: Sharing state and computation  
> with
> Croquet is quite easy. But how would one first collaborativly edit
> behavior and share it afterwards? How can one do live-sharing code?
>
> Does anyone have some hints how one could do this? Any references or
> examples?
>
> I would be so glad getting some hints, thanks a lot,
>
> Marcus

> I think the short answer is to treat code like any other resource.
>
> In practice, I have started to break this out as follows:
>
> I.  Getting resources from one island to another.
>
>   A. This always involves some sort of serialized form of the resource,
> but we're all very used to dealing with code serialized as either text
> or byte-codes. (Obviously, machine instructions won't work across
> platforms.)
>
>        1. The Island machinery has a mechanism for exporting a binary
> serialization of an object and importing that to another Island. The KAT
> code uses this to copy things from one island to another. (Example, when
> travel through a portal in the KAT, whatever you are carrying gets
> copied to the other island in this way. There's also a cut/copy/paste
> that does the same thing.)  You could use this for code objects. Note,
> though, that there is nothing yet built in to the extensible Island
> import/export mechanism for pickling/unpickling code, hooking it up to
> global references, etc.
>
>        2. Another approach is to create textual serializations (e.g., as
> xml), which has some advantages for examination by human or external
> systems, and for shielding you from version skew in the environment
> (e.g., when a class changes shape).  I've found this useful for Croquet
> objects generally, and of course, programmers have always found this to
> be true of code.  I believe that Jabberwocky will have an extensible
> mechanism for this.
>
>   B. Injecting stuff into some island to begin with can be thought of as
> simply copying the resource from an unreplicated Squeak Island (aka the
> "ocean") to a replicated Island.  There are examples of this in the KAT,
> for dragging and dropping media resources into an Island.  There is an
> additional complication in these examples that you might want to take
> advantage of for code: The KAT doesn't actually put immutable resources
> into an Island. (They take up too much space, which slows down sync'ing
> when someone joins.)  Instead, it only imports a stubb with a key made
> from the sha of the immutable contents. Then it eagerly pushes the
> external immutable resource into a shared resource manager.  (For
> implementational convenience, this operates like a "meta island" in
> terms of joining and getting resources, but syncing doesn't give you all
> the resources in the universe. Instead, they stay on the server until
> you request them. Long-term, this could be replaced by a DHT, a
> database, or whatever you like.)  Anyway, the point is that you can use
> this or something like it to manage source code resources off-island,
> which would then be shared by all the Island that use them.
>
> II. Security.
>
>     A. Who gets to introduce or change a resource? (Same issue for code
> as for any other resource.)
>
>          1. If you create a special controller method for introducing or
> changing a code resource (rather than the default #future mechanism),
> then you can use the built-in facet mechanism to securely limit who can
> do this.  This code isn't very easy to follow, but there are examples in
> the KAT.
>
>          2. I SUSPECT that it might be easier to just keep different
> resource on different Islands, and use Island access to control who gets
> to do what. The ghost frame mechanism would be used to superimpose UI
> objects from a secure island onto another Island.  The trick is that the
> secure-island objects need to update themselves from objects in the
> other Island, and we normally don't allow Island-to-Island messages.
> However, in this case, by construction, anyone who has the secure island
> would also have the other island, and so the secure objects could
> interrogate the other island objects via non-replicated messages
> #send:'s instead of #future messsages.  However, I have not gotten
> around to building anything with this idea. In the general case, this
> would require some sort of synchronization of the flow of time, and I
> haven't worked out how to bound this.
>
>     B. What does a code object get to do so as to be considered safe?
> E.g., write to disk? Open a socket?  There may be work being done in the
> Squeak community on "safe" mobile code, but I'm not aware.
>
>
> On Sep 9, 2007, at 11:12 AM, Marcus Lunzenauer wrote:
>
>> I am currently examining possible paths to implement a collaborative
>> version of Logo (or rather (Star|Net)Logo) using Croquet. All those
>> paths seem to result in one question: Sharing state and computation with
>> Croquet is quite easy. But how would one first collaborativly edit
>> behavior and share it afterwards? How can one do live-sharing code?
>>
>> Does anyone have some hints how one could do this? Any references or
>> examples?
>>
>> I would be so glad getting some hints, thanks a lot,
>>
>> Marcus
>