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

[Ken Ritchie]

Ian Bicking wrote:
> Ken Ritchie wrote:
>> www.opencroquet.org (especially the TeaTime components)
>
> I just read the "Croquet System Overview" section of this: 
> http://www.opencroquet.org/Site%20PDFs/Croquet%20Programming%201.0B.pdf
>
> It was a very nice overview of the architecture of the system.  I like 
> the approach a lot; the description of the architecture makes me want 
> to bang out code *right now*, which is always a good sign.  I'll try 
> to resist actually doing so.
>
> Whether this should be reimplemented in Python or implemented in a 
> language-neutral way, I'm not sure.  I can kind of imagine the Router 
> being a service accessible over dbus, but I'm not really sure what 
> that would accomplish.  The dbus message format is also possibly 
> something to use (since Croquet messages, I assume, are tied to 
> Smalltalk).  But I don't know if that even matters -- there's nothing 
> here that really facilitates inter-language communication, as it 
> assumes that all Islands (aka objects) use exactly the same code.
>
> 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.

/Wondering.../ Do we already have an ICT timer (per application)?

The HCI folks could recommend some nominal (default) timer value between 
keystrokes. I would expect it may vary based on accessibility options in 
use. I wonder if it varies by culture or keyboard character set?  In 
fact, since keystrokes tend toward being "bursty" (grouped in small 
batches), it would be "easy" (near-trivial algorithm) to *derive* a 
*personalized* value based on recent keyboarding behavior of the user in 
the context of the activity, influenced by  both cognitive and 
environmental factors (without having to explicitly take all those into 
account).
> So maybe I'm imagining the problem.
>
Good!  Think ahead!

cheers,
--ken [kritchie]