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 -
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
