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

[Bert Freudenberg]

On Nov 27, 2006, at 23:11 , Ian Bicking wrote:

> (Out of curiosity are any of the Croquet/Squeak/EToys people on  
> this list?)

Yes.

> Ken Ritchie wrote:
>>> 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.
>
>> Let the application designer tune an Inter-Character Timeout (ICT)  
>> for the activity, or use a built-in default. Thus, batches of  
>> keystrokes are forwarded when either: (a) the keystroke-forwarding  
>> buffer is full; or (b) the buffer is not empty and the ICT timer  
>> has just fired after the user has paused between keystrokes; or  
>> (c) the activity loses focus after the user elects to switch focus  
>> to another activity or inspect the frame or whatever.
>
> Note: there's nothing really substantive in this email, I'm just  
> thinking out loud and maybe that's helpful to do here.  Or maybe  
> it's not.
>
> Well... hmm... let me explain what I'm thinking.
>
> So, lets say Alice is typing on one laptop, and Bob on another  
> laptop, into a shared space.  At the end of the document Alice  
> types "next we must do:", and Bob types "TODO:".  The typing overlaps.
>
> My understanding of the Croquet model is that the UI would generate  
> a message to the document Island (which is where the "real" text is  
> stored).  It might be a message like ``document putText: 'next we  
> must do:' atRange: #endOfDocument``, where ``document`` is the  
> actual Croquet document Island.  The document object would update  
> itself.
>
> So there's two putText:atRange: messages that get sent out, one  
> from each of the two laptops.  The UI *already* has displayed the  
> text in the document, since the user doesn't type blindly.  And I  
> guess the UI then has to be asynchronously updated, so maybe the  
> message is really putText:atRange:notifying:, where the document  
> Island then notifies the UI about the change.  (Or maybe that's  
> just implicit somehow -- it wasn't clear from just that section how  
> exactly the UI plugs into the system.)
>
> Anyway, here's my train of thought about this:
>
> * Does the document look like "next we must do:TODO:" or "TODO:next  
> we must do:"?  Either is fine, but they both must agree.  My  
> understanding is both messages get a timestamp, and so everyone  
> agrees which comes first, so one of these arbitrarily happens.  No  
> conflict ever happens.
>
> * Then, how is that displayed?  The UI gets some kind of  
> notification of the update.  Is the UI another island of its own?   
> I.e., does Alices document editing UI get a putText:atRange:  
> message that is identical to what Bob sent?
>
> * But Alice's UI has already processed its own putText:atRange:  
> message, because it had to do so to update the screen.  Maybe what  
> the message should really be is:
>
> textAdded: textRange
> "Called periodically with typing that has occurred"
> document putText: textRange text atRange: textRange range
>          after: [self removeRange: textRange].
>
> And then when the message is received by the document, it will then  
> call the after: block, which will remove the text that was typed  
> in.  And simultaneously with that, it should update the rest of the  
> document based on the document Island's internal state (which would  
> add the text in at exactly the same time, so it would appear the  
> text was always there).  Then the text that was interactively  
> entered but not confirmed by the document Island would get  
> periodically removed and replaced with the text that was stored in  
> the Island, along with any text that came from other sources (like  
> Bob's updates).
>
> So while the document the UI presents may shift under the user  
> (inevitably, since there's collaborative editing happening), the UI  
> would never block waiting for an update from the document Island.   
> I guess this is not unlike in a multiplayer game where (with a bad  
> connection) you will be walking around with seemingly complete  
> freedom, until you sync up with the server and you jump back into  
> your "real" location and suddenly see what really happened in the  
> world.  In a game that usually means that some of what you said to  
> do either was ignored, or what the UI made you think you were doing  
> was wrong.  E.g., you were walking forward and the UI shows you  
> walking forward, but you were actually blocked by something; in  
> that case the message is really "try to walk forward", and you  
> really did try, so the message was never ignored, but the UI gave  
> bad feedback.  I'm not sure I'm comfortable with an editor sending  
> messages like "try to put this text somewhere". Or, if it fails,  
> the UI needs to give better feedback than just jumping to a new  
> synchronized state.  So maybe that just means adding  
> "onSuccess:onFail:" to each message from the UI.

All messages sent to a replicated island go trough the shared router,  
which attaches time stamps. So there never is any doubt about the  
state of the replicated island.

Now, the UI is in a non-replicated island, and it's up to the  
programmer to deal with that. You could have your text appended to  
the text widget speculatively (typing ahead), which in most cases  
works fine, but then a little later you'll get the authoritative  
notification from the replicated island and you would have to deal  
with making sure you display that one.

- Bert -