[info] [croquet-dev] A black-and-white proposal

Sat Dec 1 20:24:03 UTC 2007

----- Forwarded message from "David P. Reed" <dpreed at reed.com> -----

From: "David P. Reed" <dpreed at reed.com>
Date: Sat, 01 Dec 2007 14:52:17 -0500
To: croquet-dev at duke.edu, David Faught <dave.faught at gmail.com>
Subject: Re: [croquet-dev] A black-and-white proposal
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.5) Gecko/20070727 Fedora/2.0.0.5-2.fc7 Thunderbird/2.0.0.5 Mnenhy/0.7.5.0
Reply-To: croquet-dev at duke.edu, "David P. Reed" <dpreed at reed.com>

David, I think this is a really neat conceptual framing of a powerful idea.

However, I think the place to do it is not at the messaging/replication 
layer of the system.  There just is no really good way to stare at the 
individual Croquet messages, or the object message processing semantics 
and compute (using some deterministic algorithm) how to partially replicate.

The idea of replicating some objects and not others is part of the 
design of TeaTime, and was in fact implemented by me.  

At the moment, for pragmatic reasons (and historical ones that are best 
explained in a private setting, regarding the decision to abandon the 
full TeaTime design made by Andreas, with my temporary assent) the full 
TeaTime replication architecture is not implemented.

This is in some sense analogous to the LISP 1.5 pragmatic decision to 
choose not to implement lambda-calculus closures - but instead to limit 
the LISP semantics to those that can be implemented on a stack machine 
based on so-called applicative-order evaluation.  That decision was made 
pragmatically because the expressive value of closures was not thought 
to be worth the complexity.

The same thing has happened to "full TeaTIme" replication semantics.   
Qwaq does not need it to ship a useful product, nor does the open source 
Croquet need it at the moment.

Instead two low-level hacks were implemented: "islands" and "routers".   
These are pragmatic solutions that are like the "stack-only" choice made 
by Lisp 1.5.  Don't get me wrong - they are elegant hacks, well 
crafted.   And some day they might be modified to support the original 
TeaTime full semantics.

I view that as similar to the introduction of full closure semantics in 
the form of Scheme (a wonderful extension of the LISP world, crafted by 
people who understood the value of closures, as well as the value of 
other key ideas that were omitted in LISP).  Scheme's creators set 
themselves the challenge of going beyond the "hack" and doing 
lambda-calculus right.

Now if we look back at LISP - AI did very well at using LISP without 
closures for a long time.  So I don't think Croquet will be harmed too 
much in its impact by omitting the full TeaTime replication semantics, 
however important I think they are, and however much it's a cool idea to 
do adaptive and partial replication to make apps do things like those 
you suggest.

And I think, /if one is careful not to throw too many hacks that cruft 
up the low level semantics of Croquet into the system/, the full TeaTime 
semantics might be slipped back underneath Croquet with little impact at 
some time in the future.  The biggest thing that made Scheme 
incompatible were all the hacks like FEXPRs, macros, and strange uses of 
eval and apply that were used to compensate for lack of closures in the 
original LISP implementations.  ANd the hardest thing about introducing 
closures was that they tended to make the system run a few percent 
slower, which the community freaked out about whenever it was tried.

If full TeaTime never makes it into Croquet, well, I've been exploring 
extensions to the full TeaTime ideas in other forms, other places.   
Perhaps we'll have to do a new system someday... one not called Croquet, 
but which addresses, for example, the heterogeneity of end-user devices 
that underly your concerns.  Not just by a richer replicated computing 
semantics, but by new thinking about user experiences beyond just 
copying of Second Life's capabilities.

Croquet is a worthy endeavor, one that I support.  But it also needs to 
move at a technologically slower rate right now.  New innovations are 
probably not so important as expanding the user base, and expanding the 
developer base, mostly by keeping it stable.

Good software engineers like Andreas and David Smith and Mark McCahill 
are doing a good job at stabilizing and completing a good thing.  The 
time for research and experimentation is not now, and I've accepted that.

- David

David Faught wrote:
>Prompted by the idea of the black-and-whites in Neal Stephenson's
>"Snow Crash", which were a low bandwidth/resolution avatar
>representation in the Metaverse, and by participation in Qwaq Forums
>with my poor old home system (aaawww), which generally limits me to
>listening only to the voice and participating in the text chat (I am
>able to talk and move about the 3D space, but the response lag for
>those things is usually so bad that they are not worth doing), I would
>like to propose the idea of selective replication.  I brought this up
>briefly in the developer's meeting yesterday, but thought that it
>might be worth a little more ink.
>
>First of all, I am far from a guru when it comes to the internals of
>Croquet routing and replication.  I am just going by what little I
>know and by my own subjective experience in Croquet collaborative
>spaces.  But I'll say this anyway.
>
>By categorizing messages going through the Croquet router (maybe by
>their originating Class?) and by having router clients subscribe to a
>few categories of messages when they join a space (in a similar manner
>to HTTP header ACCEPTS?), it might be possible to include a greater
>number of clients with varying capabilities.  I'm not sure exactly how
>this relates to facets, which are usually taken as a security control
>mechanism, but there may be a fairly direct relationship.
>
>Specifically, what I have in mind would allow one client to subscribe
>only to text chat messages, another client to subscribe only to the
>text chat messages and voice messages, and a third client to subscribe
>to all messages being replicated from the same island.  These clients
>could potentially all use the same code base (as a starting point),
>but that might not be a requirement.  An implication of these varying
>levels of subscription is that the client would not generate messages
>outside of the categories that they are subscribed to.  There could
>easily be other media categories such as movies, active simulations,
>etc.
>
>It may be reasonable to put most of the processing for this message
>selection and subscription right in the Croquet router.  The extra
>burden of filtering messages might be offset by the savings of not
>needing to send all messages to all clients.
>
>One scenario that I could see (my personal favorite) would allow a
>client with the same code base as full function clients to subscribe
>to only the voice and text chats from a space.  This client would only
>be able to interactively participate with voice and text, but they
>might still receive an initial snapshot, or even periodic snapshots,
>of the 3D space.  Some other process would be needed to generate those
>snapshots though.
>
>Another scenario might allow someone on a cell phone to participate
>through text messaging, voice interaction, or even an occasional
>snapshot picture message, possibly through a proxy server of some
>kind.
>
>I'm sure that this idea or something very similar has come up in the
>Croquet community before, but I am trying to keep it alive as a viable
>direction for improvement.  What do you think?
>
>Cheers,
>Dave
>
>  

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE