A black-and-white proposal

> 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
>
>  

> 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
> >
> >
>

> 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.