[sugar] "Garden": A (currently hypothetical) Sugar library for sharing state between Activity participants
Ian Bicking
ianb
Mon Nov 27 17:11:55 EST 2006
(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
More information about the Sugar-devel
mailing list