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

[Ian Bicking]

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


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.


-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org