chromium

dmoc :
Chromium read was interesting. I've downloaded freemind .

The idea of network traffic taking openGL up the pipeline for distributed visualization of supercomputer information. Supercomputers and multiprocessing and distributed processing produce a lot of data and I've read this makes such architectures push development in graphics and I should easily imagine distributed graphics.

But, the chromium read wasn't conducive to my saying or doing anything, it seemed like an ad or management brief . I might invest in its stock, but I don't believe these folks would mumble with me as I like to do. I suppose they have their government contracts, discuss on a need to know basis, and are not so much "librarians" or better "watched librarians" as the croquet list . They probably are a high profile high turnover profession, not a place to find lasting friends in a peculiar nitch . That is what I am looking for as I've tried high turnover and now want to try something else. I hope not to merely aggravate evangelism with evangelism . I don't think trying a life tactic has to be construed as pushing it on another . I hope, by introducing my choices, I am merely inviting folks to see how I turn out and if what I try "works".

I hope I have been kind above .

Croquet isn't just about graphics sharing, its doing with images makes symbols for whole open operating systems on a virtual machine that doesn't care where it is (following the definition of object oriented programming (oop) according to an encyclopedia of computing in my library) funded initially by the guy who invented oop idea and the idea of the laptop in his thesis.

I believe folks should go along their journeys on separate ways and try to bring back , but I am afraid of behaviors amongst my friends that, when I go off and try something, I get waysaying saying that maybe I should instead try what they recommend.

Oh in 1982 Tim Gallway taught music and no one questioned him as not a music major . He just asked them to be self-aware, a bit different than a neophyte evangelizing, so no one ever thought to be offended or question his professional nature .

Sorry, I think I may have replied to the wrong post and because I favour brevity over verbosity
(personal preference, no offence intended or inferred(?)) it may appear as if I expect others to
be mind readers, lol. My response was to Florent/Josh's post re casting/embedding external apps in
a Croquet "window" and specifically opengl apps. I also failed to address possibly problems of
sync'ing these apps. So here is my second stab...

To avoid misunderstanding I define "external" to imply app's that were never designed to be
embedded in another app, although to be dogmatic they typically *are* embedded, even if it is only
within the OS/GUI, conveniently ignoring those few which want the whole machine, typically games.
What is wanted is to intercept the app's output, route it to Croquet and then route inputs from
Croquet back to the app (in an ordered manner, more on this later). VNC-ish but with an emphasis
on performance when coupled with Croquet. I mentioned Chromium in specific response to doing this
for OpenGL app's. Chromium can intercept OpenGL commands and forward them to a remote machine.
This machine would in practice be a nominated Croquet client acting as a bridge, routing the
commands to other Croquet clients as typical on-island messages or off-island "future" messages,
leaving Croquet to handle sync'ing as it is designed to do. I should perhaps say "in theory"
because while possible I can only truly say "it's possible" if not entirely practical at the
current time.

My specific point is that routing ogl commands should not be discounted because while the
resulting frame rate will be lower than running a local app, it may still be faster than shunting
bitmaps around from a VNC-like app, even with compression. OGL offers greater scope for efficiency
since much could be cached on the client... in fact as I write this it occurs to me that an
embedded X-Server would meet all the requirements! OK I may be slow at arriving at this
conclusion, lol, in my defence I have been up all night :-))) I will be surprised if this idea
hasn't already occurred to the Croquet developers. And having arrived at this conclusion it's time
for bed after a few final comments...

Regarding the possibility of sync'ing problems, specifically for the example used where the
external app is a web browser: AFAIK (I'm still learning this stuff) it won't happen in Croquet
because whoever is pointing at a window effectively has ownership. I'm sure there are a few
creases to iron-out and some special cases will arise but I would expect the current avatars
actions and results to be replicated before relinquishing control to another, precluding the
situation stated in the example.

Related but different from the above, I see at least two scenarios where Croquet constraints
should/could be relaxed. One is what I refer to as "Ambient Aspects". These are aspects that are
not critical to the Croquet "simulation" (to use Croquet terminology) and a prime example in the
supplied demos would be the sky-map, ie, does it really matter if your view of the sky is
different to mine if the focus of the simulation has nothing to do with the sky? Another example
would be water effects or the Alan Kay portal, here it's the *essence* of the simulation that
counts and the question of all clients being in-sync is (almost?) irrelevant. The other scenario
is "Private Aspects", ie, objects/features in shared islands but not-replicated and thus invisible
to others. In-island monitoring/control/usage-stats type "widgets"... which I'll leave there as
I'm pretty sure this is already catered for in Croquet... but then I've only read the dev docs
three times, which leads to my final comment and the one least related to the OP (so sorry for the
high jacking!)...

Although I am very pro traditional documentation, it seems somewhat ironic to me that I'm trawling
documents about a system that is ideal for visualizing it's own concepts! How about a
fun-competition to create Croquet demos that demo Croquet itself? Of course I expect the prize to
be some sort of virtual trophy modelled and presented in Croquet. What say thee?

And with that I'm off to my own sleepy island (no public router)... did I say something about
preferring brevity? See ya :-)



--- Paul Sheldon <[hidden email]> wrote:



      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

On Apr 24, 2007, at 2:23 AM, dmoc wrote:

This is a good point.  It is an open question whether this approach  
is feasible from a performance standpoint; the answer almost  
certainly depends on the characteristics of the OpenGL app that is to  
be embedded.  This requires more research... any volunteers?  :-)

That actually doesn't save you.  If you're replicating the UI events,  
then one user can grab the window focus, click on a link, and then  
immediately click on another link as soon as the page has loaded.  
Another user can still receive the second click event before their  
local browser has finished loading the page, and therefore end up in  
a different state.

Agreed about both Private and Ambient Aspects.

Josh

--- Joshua Gargus <[hidden email]> wrote:

I may "tinker" at some point although I cannot commit to any time scale. I will pencil it in for
the next month of Sundays :-)

Hmmm, the first page load is transient, the request for the second page *has* gone to the
remote/app'n server/session. Other users, at worse, will see a "glitch" and at best won't even
notice, iow a transient action results in a transient state, possibly not even registering with
other users perception (smacks of "If a tree falls and no one sees it..."). This is assuming the
absence of a mechanism to stall further input to the app (mouse click in this instance) until it's
on-island display has at least updated one full frame. To be explicit, the problem in your
scenario is other users seeing a page which may not even have had a link on the original page. I'm
not sure of the generality of the problem or the gravity of any effects resulting from it. Do you
have more examples of how/where this scenario will have a concrete impact?

A very similar situation: just as in normal usage, if I'm quick (or my connection is slow) I can
click another link in the *same* page before it has chance to load the first requested page.

I meant of course "hijacking" but it's good to see I have an ally... first step to world
domination :-))))




      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/ 

On Apr 24, 2007, at 9:27 AM, dmoc wrote:
I'm a bit confused.  To be clear, I thought that we were talking  
about a non-VNC solution where each client is running their own web-
browser (with the benefit of more immediate interaction, and with the  
downside that I am about to describe again).  For simplicity, let's  
assume that these browsers are identical.  I'm also assuming that the  
only events that are being replicated are UI events (mouse clicks and  
keystrokes), not higher-level events like "URL changed to".

Given this setup, let's say that I'm on a really fast connection and  
you're on a 56K modem.  I enter 'slashdot.org' into the URL bar, and  
the page quickly appears; I then click on the link for the top  
story.  You receive that click while your slow modem is still  
downloading animated advertisements for Intel Xeons; the click is  
ignored because the link hasn't yet been rendered on your page.  The  
end state is that you remain on /. while I am on the page with the  
top story.

Other things can go wrong, too.  If you have different fonts on your  
computer than I have, or your web-browser uses a different theme,  
then the link might be rendered at a different position on your page  
than on mine; again, the replicated click might not be on the link in  
your browser.

A VNC-like solution avoids these problems, at the expense of a more  
sluggish UI.  If you have the slow connection, you might simply not  
see the first page, but would eventually end up seeing the same thing  
as me.

I think that you probably understood all of this, and that we simply  
had a miscommunication somewhere.

Cheers,
Josh

About sluggishness....

If i'm not mistaken, any event/computation is replicated among all
users in the island, right? Which means that, even if somebody does
not see the action, he has to download the replication nonetheless,
right?

I forgot how it's called, but the graphics industry uses such a
technique to spare computation: no need to draw some 3D you don't see
(behind a wall for instance).

Isn't it possible to trigger computation replication based on visibility?

Another "sparing" could be done for textures, 3D models, (if you don't
come close, you only see the low-res version from far away),
animation, voice... But these are nowadays not an issue considering
croquet's relatively small islands size. Yet, if a gloal 3D space ever
links all the croquet spaces together, this type of optimization may
come in handy...

Florent

On Apr 25, 2007, at 1:21 AM, Florent THIERY wrote:

> About sluggishness....
>
> If i'm not mistaken, any event/computation is replicated among all
> users in the island, right?

Every computation that is replicated among all users in the island is  
replicated among all users in the island, yes ;-)

But not all computations are necessarily replicated in the island...

(see below)

> Which means that, even if somebody does
> not see the action, he has to download the replication nonetheless,
> right?

Fortunately, not always (see below)

>
> I forgot how it's called, but the graphics industry uses such a
> technique to spare computation: no need to draw some 3D you don't see
> (behind a wall for instance).

"occlusion culling"

>
> Isn't it possible to trigger computation replication based on  
> visibility?

Yes, you are exactly right.  In fact, this already happens during  
rendering; objects are contained in hierarchical bounding spheres,  
and if a bounding sphere does not intersect the viewing frustum, it  
is not rendered.

One might also think about things like not streaming video to  
participants for whom the (virtual) video screen is not visible.  Or  
even doing the same thing for VNC.

Getting back to the original point, none of this does anything to  
alleviate the sluggishness of interacting with a VNC-application  
(although it may make things better for those who are in the space,  
but aren't interacting with the VNC app, since they wouldn't receive  
the data).

Cheers,
Josh

>
> Another "sparing" could be done for textures, 3D models, (if you don't
> come close, you only see the low-res version from far away),
> animation, voice... But these are nowadays not an issue considering
> croquet's relatively small islands size. Yet, if a gloal 3D space ever
> links all the croquet spaces together, this type of optimization may
> come in handy...
>
> Florent

I'm not really following how a Chromium app would work. It might work as a sort
of "better VNC". It could be that the Chromium app is running on a single
bottleneck server, but that instead of sending damaged rectangles back across
the wire, it sends drawing instructions.

I'll define my terms:

REMOTE APPS: At one extreme of an external app, we have a bunch of replicated
VNC clients communicating with a shared session on a VNC server. It works. On
the one hand, doing this on panels within Croquet provides a lot of context and
gives external apps some (but not all) of the benefits of Croquet. On the other
hand, there's some extra memory copying and so it might be slightly slower in
principle than a stand-alone 2D VNC client. I don't know if that matters in the
grand scheme of things. (The current KAT implementation is certainly slower.)
The current architecture is also going to be one round trip slower than
stand-alone VNC, but it doesn't have to be. In any case, VNC within Croquet is
not going to be faster than a stand-alone 2D VNC client. I find that I cannot
play video games over stand-alone 2D VNC.

LOCAL APPS: At the other extreme is individual copies of local applications,
each displayed in a replicated window in a replicated Croquet world. As Josh
described, this will only work when two requirements are met:

  1. The applications must produce the same deterministic results when given the
same inputs in the same order. The inputs cannot depend on real time, network
activity, machine state (e.g., for entropy generators or for additional files
that may or may not be there), or numeric computation.

  2. When someone joins late, the app has to have some way to get to the same
state. Maybe there's little enough interaction that this can be done by
replaying saved Croquet inputs. But if that takes too long, there has to be a
way to serialize the current state and get that to the newly joined participant.

Fortunately, there are a lot of legacy applications that this will work for. For
these cases, the results should be just as snappy as Croquet in general. Again,
there may be the same extra memory copy. Modulo that, with a little
re-engineering, there are SOME kinds of applications where we could make it as
snappy as running the application locally, outside of Croquet.

Although this can give better performance than remote bottlenecked apps, local
apps are not as general. We don't have a general plug-and-play local app
mechanism in the SDK right now.

------------------
Separately: it is true that pointing at a window gives ownership. But that's a
property of the current default UI, not a fundamental consequence of the Croquet
model.

Joshua Gargus wrote:
--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
office:+1-608-262-3724
mobile:+1-608-658-2419

Howard Stearns wrote well --- I fear deathly silence as a response so
chime in hopefully not abnoxiously,
I also fear being accused of not being technical after I unload a bit of
philosophy I've been working on,
so I try to affirm that I understand some of the technical --- I also
like reading things the good professor writes
that I can't currently understand or what's a heaven for? :

> I'm not really following how a Chromium app would work. It might work
> as a sort of "better VNC". It could be that the Chromium app is
> running on a single bottleneck server, but that instead of sending
> damaged rectangles back across the wire, it sends drawing instructions.

I wondered at the term bottleneck server .

I googled in quotes for :
http://www.cs.utah.edu/classes/cs7460/lectures/lecture2.txt

"Topic: Scalability and good design practices

    Discussion topic: What can lead to POOR scalability?


    Centralization is often a culprit:
        - centralized services --> bottleneck server(s), fault intolerance
    - centralized data --> high latency, bottleneck server(s), faults
    - centralized algoritms --> load imbalance, hotspots

    Some characteristics of good distributed algorithms:"

But, remembering Vivarium, I might like little tiny (poor?) children of
Palo Alto to play with supercomputers because the commercial markets
might not have so much imagination or might (I read a free book sent me
by Smarr and Kaufman on commercial uses of supercomputers). Distributed
processing, however, is supercomputing . Collectively, with distributed
processing, poor people could own a supercomputer .

>
> I'll define my terms:
>
> REMOTE APPS: At one extreme of an external app, we have a bunch of
> replicated VNC clients communicating with a shared session on a VNC
> server. It works. On the one hand, doing this on panels within Croquet
> provides a lot of context and gives external apps some (but not all)
> of the benefits of Croquet.

Does that mean that my poor construction worker family will have to get
four computers to not fight over who uses croquet? I think you are
pushing for distributed processing rather than having the children share
a cpu .  We might imagine distributed graphics processing would be cheap
with the cheap graphics cards mentioned this list .

> On the other hand, there's some extra memory copying and so it might
> be slightly slower in principle than a stand-alone 2D VNC client.

I think we're fumbling around studying candidate network architectures
for candidate management of creative people. I am trying to write a
piece about "the angst of Penny at Stanford against the Stanford-Binet
IQ test". She wanted to study learning and teaching candidate strategies
rather than have children be the candidate study.

> I don't know if that matters in the grand scheme of things. (The
> current KAT implementation is certainly slower.) The current
> architecture is also going to be one round trip slower than
> stand-alone VNC, but it doesn't have to be. In any case, VNC within
> Croquet is not going to be faster than a stand-alone 2D VNC client. I
> find that I cannot play video games over stand-alone 2D VNC.

I hope the implication is that croquet, rather than merely control each
others computers, will allow creative people to play with each other
better .

>
> LOCAL APPS: At the other extreme is individual copies of local
> applications, each displayed in a replicated window in a replicated
> Croquet world.

One can study a situation by studying extremes, extremes that might be
ludicrous, but, nonetheless, illuminating .

I wonder that visiting another person's world means you share their
total experience . My brother wishes that people would go into phone
booths with their cell phones so he wouldn't have to hear about their
business . He is jealous that they aren't really accessible . Creative
collaboration isn't folks in lock sync replicating the totality of each
others lives . Its something else .

> As Josh described, this will only work when two requirements are met:
>
>  1. The applications must produce the same deterministic results when
> given the same inputs in the same order. The inputs cannot depend on
> real time, network activity, machine state (e.g., for entropy
> generators or for additional files that may or may not be there), or
> numeric computation.

The use of the words "machine state" suggest this croquet model may be
related to automata theory and state machines. I remember my profound
shame at failing a course in artificial intelligence and my tears of joy
at working my heart out on automata theory one summer. I felt I had
recovered my honor and soon after started beta testing LiveMath computer
algebra wondering if I could understand it as a state machine like my
early Hewlett Packard 32 instructions summarized a whole book of
instructions in a flow diagram state machine.

I hated when the "old boys" at Rockwell tried to impose flow graph
expositions of code, but, privately, later, in CS I became reinvigorated
with that HP experience .

Entropy has references in network theory and Shannon information theory
. Programming has as fundamental the way you store work or record . In
my time asymmetry studies, you only record (files) by generating entropy
. If you didn't, you couldn't.

I think what is being spoken of is an application must be like science
having reproducible results so consumers can count on their behavior .

>
>  2. When someone joins late, the app has to have some way to get to
> the same state. Maybe there's little enough interaction that this can
> be done by replaying saved Croquet inputs. But if that takes too long,
> there has to be a way to serialize the current state and get that to
> the newly joined participant.

There are candidates being thought of for getting this "scientific
reproducibility" and accountability .

>
> Fortunately, there are a lot of legacy applications that this will
> work for.

what the croquet model would be good for ...

> For these cases, the results should be just as snappy as Croquet in
> general. Again, there may be the same extra memory copy. Modulo that,
> with a little re-engineering, there are SOME kinds of applications
> where we could make it as snappy as running the application locally,
> outside of Croquet.

be just as good for

>
> Although this can give better performance than remote bottlenecked
> apps, local apps are not as general. We don't have a general
> plug-and-play local app mechanism in the SDK right now.

I think you are saying the croquet model can give better performance
than remote bottlenecked apps, however its local apps are not as general
because they need the two restrictions above .

>
> ------------------
> Separately: it is true that pointing at a window gives ownership. But
> that's a property of the current default UI, not a fundamental
> consequence of the Croquet model.

I think this being not a fundamental consequence of the Croquet model is
"good" and has something to do with not programming modally .

Comments below, but first some general stuff:

I think it's perfectly fine to like Croquet because it exists, or because it's
open source, or written in Smalltalk, or whatever reason one wants. But to me,
the interesting part is how the model differs from other distributed systems,
and what the potential consequences are of that model (e.g., scalability,
safety, etc.).

As I see it, that core model is -- just as Paul says -- about reproducing
results. Other distributed systems are about synchronizing results. The key
insight of Croquet is that the same inputs at the same "time" will produce the
same results for the same initial conditions. The entire computation is
(re-)executed the same way on each participating machine. Given the careful work
by smiTh, reEd, and raAb to make this happen, collaborative applications can be
simpler, safer, more scalable, and more integrated with each other and their
context. It does NOT have the effect of offloading different parts of the
computation to different machines. We think this is ok because processors are or
will be plenty cheap enough. I'd rather be more sparing in the use of people
than of silicon.

Now, you could use Croquet's cool graphics and neato development environment to
do distributed processing rather than replicated processing, but I don't think
that's really playing to Croquet's deep core strengths.

The part of this discussion thread that I tuned in to was about providing access
to legacy content that was not implemented in Croquet. It is interesting to me
to consider not just how legacy content can be included at all, but how to do so
while preserving Croquet's benefits for Croquet content, and maybe even
extending some of those benefits to the legacy content. The exposition was
between systems like VNC that centralize the legacy application to one processor
and distribute the results, vs. having a copy of the legacy application on each
machine. The problem with doing the latter is that many legacy applications
simply don't have a good way to maintain the Croquet (TEA-time) invariant:
results might be different for different copies on the network, even when the
inputs are funneled through Croquet.

c.f. http://opencroquet.org/index.php/The_Core_Model

Paul Sheldon wrote:
> Howard Stearns wrote well --- I fear deathly silence as a response so
> chime in hopefully not abnoxiously,
> I also fear being accused of not being technical after I unload a bit of
> philosophy I've been working on,
> so I try to affirm that I understand some of the technical --- I also
> like reading things the good professor writes
> that I can't currently understand or what's a heaven for? :


Hah! I'm on staff in the IT department of the University of Wisconsin -- not a
professor. I don't have any Computer Science degree at all. Google me if you're
bored.

>
>> I'm not really following how a Chromium app would work. It might work
>> as a sort of "better VNC". It could be that the Chromium app is
>> running on a single bottleneck server, but that instead of sending
>> damaged rectangles back across the wire, it sends drawing instructions.
>
> I wondered at the term bottleneck server .

I just mean "bottleneck server" as a disparaging term for a single centralized
server, and emphasizing that that this puts limitations on performance.

I think I may have first heard David Smith say something like "bottleneck
provider" in referring to an Internet Service Provider. It could have been
someone else.

Mind you, the current version of Croquet turns limitations like these into a
feature by making all messages go through a router for the purpose of
timestamping and authentication.

See intro, above.

Right. The hope is that all approaches to legacy apps from within Croquet -- not
just only remote or only local -- would allow people to work together IN
CONTEXT. VNC by itself (outside of Croquet) doesn't really do that.

Technically, TEA-time is about being in lock sync, replicating the totality of
the simulation. One philosophically interesting thing is that rendering is NOT
part of the simulation and is not replicated -- every participant has their own
point of view.  So, the boring mechanical part of the COMPUTER system is about
being in lock step. But the value and raison detre of the WHOLE COMPUTER-HUMAN
system comes from the individual (non-replicated) points of view of the
participants.

I think it is best to NOT think about machine state for real Croquet
applications. Just think about replicated messages and behavior.

Alas, legacy applications are not Croquet. They do tend to be oriented around
"state" and "data."

Yes.

Agreed.

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
office:+1-608-262-3724

On 4/29/07, Paul Sheldon <[hidden email]> wrote:
Supercomputing means a lot of things to a lot of people.  My personal
take on it is that it is any situation where several computers are all
programmed to perform portions of a much larger calculation.

Croquet is not 'supercomputing' under this view.  Croquet is
'distributed processing' -- rather than have a single server that
performs all the calculations and then distributes the results of
those calculations, Croquet distributes the data to perform the
calculations and the calculations to be performed.  This allows each
participant in the world to calculate the simulation state
independently.

You're rather missing the point here.

VNC is a means of transporting the framebuffer output of a session --
be that session an X server, a Windows desktop, a MacOS desktop, or
anything else.  It has the ability to transport this framebuffer to
multiple locations, and all of them can share it.  However, the
processing that creates this framebuffer must put its output in a
single place -- the 'host' of the framebuffer.  (Multiple X clients
from multiple machines can output to a single Xvnc session, but that's
only because of the X protocol.)  VNC doesn't lend itself to taking
the applications that output to it and letting them run across the
multiple VNC client machines ('application sharing').

> > On the other hand, there's some extra memory copying and so it might
> > be slightly slower in principle than a stand-alone 2D VNC client.
>
> I think we're fumbling around studying candidate network architectures
> for candidate management of creative people. I am trying to write a
> piece about "the angst of Penny at Stanford against the Stanford-Binet
> IQ test". She wanted to study learning and teaching candidate strategies
> rather than have children be the candidate study.

Actually, we're looking at the History -- those that do not learn from
history are doomed to repeat it.  We're looking at the characteristics
of what's happened before, and trying to figure out what
characteristics are good versus what characteristics should be left by
the wayside.

I believe that this is what it's always tried to do.

Croquet creates a simulation, and the simulation is distributed such
that any subset of the individual simulation clients can continue the
simulation even in the absence of the original location where the
simulation was obtained.

> > LOCAL APPS: At the other extreme is individual copies of local
> > applications, each displayed in a replicated window in a replicated
> > Croquet world.
>
> One can study a situation by studying extremes, extremes that might be
> ludicrous, but, nonetheless, illuminating .

Again, without examining the history and characteristics of that
history, there is relatively little room and capability to advance the
art and the science.  Sometimes situations themselves must be studied
and examined, to determine how best to modify them.

> I wonder that visiting another person's world means you share their
> total experience . My brother wishes that people would go into phone
> booths with their cell phones so he wouldn't have to hear about their
> business . He is jealous that they aren't really accessible . Creative
> collaboration isn't folks in lock sync replicating the totality of each
> others lives . Its something else .

Creative collaboration isn't the situation of being in lock-step in
the totality of life.  However, there is a very important aspect of
collaboration which you appear not to recognize:  In order to
collaborate, two or more must communicate.  In order to effectively
communicate, there must be at least some aspect of experience which is
shared (sensed independently).

Croquet is a means of sharing experience.  In order to effectively
share experience, Croquet replicates the state of the simulation in
such a way that it can be sensed in more than one location, in
multiple ways (however it makes sense to sense it).

Croquet is NOT a means of forcing people to think the same way.  It is
a means of sharing information such that the computers (clients) that
people use can do their own processing on that information.

Short answer, yes.

Croquet can be viewed as:
a) the data that makes up the simulation
b) the behavior which allows the simulation to proceed.

Perhaps not-so-oddly, an "object" (in object oriented programming) can
also be viewed that way -- the data, and the operations which can be
applied to the data.

Because one of the requirements of the Croquet simulation is that each
one must be able to continue independently, the machine must be
deterministic.  This means that it is a state machine -- because with
each input, it can be determined from the knowledge of the entire
simulation how the simulation will change.

If any of the clients become out-of-sync, then input which is
meaningless will be given to other instance simulations, which may
cause them to behave erratically at best or meaninglessly at worst.

> >  2. When someone joins late, the app has to have some way to get to
> > the same state. Maybe there's little enough interaction that this can
> > be done by replaying saved Croquet inputs. But if that takes too long,
> > there has to be a way to serialize the current state and get that to
> > the newly joined participant.
>
> There are candidates being thought of for getting this "scientific
> reproducibility" and accountability .

Let's look at it this way: as soon as there is a way of writing out
the state of the simulation to disk, there is a way of writing out the
state of the simulation to a new client.

(To see the truth of this statement, look at the concept that "writing
out the state of the simulation to disk" is "getting the state of the
simulation ready for a new client".  Then, if the current simulator is
killed, creating a new simulator and then "loading the state of the
simulation from disk" is the same as "synchronizing the simulator to a
different simulation state" -- no matter that it may have been
time-shifted.)

> > Although this can give better performance than remote bottlenecked
> > apps, local apps are not as general. We don't have a general
> > plug-and-play local app mechanism in the SDK right now.
>
> I think you are saying the croquet model can give better performance
> than remote bottlenecked apps, however its local apps are not as general
> because they need the two restrictions above .

The concept of a 'remote bottlenecked app' is something where there is
only /one/ place to obtain the information necessary to update the
simulation state.  it is also something where only /one/ place must
become unreachable for the application to become unusable.

Unfortunately, this matters.

> > ------------------
> > Separately: it is true that pointing at a window gives ownership. But
> > that's a property of the current default UI, not a fundamental
> > consequence of the Croquet model.
>
> I think this being not a fundamental consequence of the Croquet model is
> "good" and has something to do with not programming modally .

I rather wish that I could find