Smalltalk › Squeak › Croquet › Croquet - Dev

[croquet-dev] About persistence and a master space (was Selective access)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Kelly Rued-2

[croquet-dev] About persistence and a master space (was Selective access)

Thanks! You've given me a good idea where to start. :)

Also, am I misunderstanding the point of the "master space" in thinking that it would be used to help users store persistent world data (and changes to the world data) in a central repository of sorts? I guess I thought that the master space *was* a persistent copy of a croquet island that was always running so that participant copies could be imaged from the master and reflect a current up-to-date state.

I suppose the master space could always be used to "serve" a fresh reset copy of a space to a new user or group of users but then I'm not really sure what good that does in a lot of collaborative spaces. It works for a conference room type of situation where you might want a fresh, clean space each time you meet there and each group doesn't need to leave records of their collaborative work for other users to access when they are offline (or rather when their copies of the island are offline), but there are other times when you would probably want the changes users make to be persistent in something like a master copy (most people won't be able to leave their island running 24/7 unless it's on a server). If we join a space together and make some cool changes, then we both need to run resource hungry programs (maybe Second Life, lol) so we have to shut down our croquet islands on our PCs... how do our collaborators get to our work when our copies of the island are offline?

Was the concept of a master copy intended to save the "last active state" of the island (changes recorded the last time copies were connected besides the master itself), does it just serve a "default image" of what the island looks like when everyone first arrives (no user collaborative changes?)... or can it do either depending on the application? If no master copy is always online (typically on a server) then what have people been doing to sync croquet island user changes?

Is anyone storing persistent shared world/user data in a database (on a server) rather than constantly running a croquet island to be the master or island image? Couldn't each copy of an island write local copy changes to some kind of changelog process on the server that records the saved states (maybe even multiple diffs, like a wiki) in a central database so anyone initiating a new copy of an island could get the last known persistent data, even if their copy was presently the *only* copy of the island running online? The server wouldn't be sharing computation with croquet spaces but rather running checks and balances on the data updates sent from all of the collaborating copies so there would always be a live and "current" version of persistent island data. Even cooler would be if it was organized Gmail thread style so that you could look back at the past x images of the island and see who "changed" what (and be able to roll back changes if need be). Although that might be getting too wiki on the island concept. ;p

Heh, sorry for all the questions. I'm just trying to wrap my head around how croquet was envisioned to handle persistence with full p2p and no central server managing the persistent bits.

Thanks for all the great info so far,

Kelly

With respect to running a "master space" (which, I should point out,
is not a core Croquet concept... others have experimented with
storing a description of a world on a server; the first person who
tries to join the world creates the world from this description
rather than syncing with an always-running island replica) on Linux,
I think that pretty much any version of Fedora should work. The
persistent copies of Croquet Collaborative islands run on FreeBSD,
which is definitely a less common Squeak/Croquet platform. I would
again recommend looking at the Croquet Collaborative codebase, which
goes to some lengths to allow running a "headless" (no OpenAL/OpenGL)
Croquet image; this has the dual benefits of reducing the
computational load on the "server", and of reducing the dependencies
you would otherwise have on a properly installed OpenAL and OpenGL.

Joshua Gargus-2

Re: [croquet-dev] About persistence and a master space (was Selective access)

On Feb 7, 2007, at 10:29 PM, Kelly Rued wrote:

> Thanks! You've given me a good idea where to start. :)
>
> Also, am I misunderstanding the point of the "master space" in
> thinking that it would be used to help users store persistent world
> data (and changes to the world data) in a central repository of
> sorts? I guess I thought that the master space *was* a persistent
> copy of a croquet island that was always running so that
> participant copies could be imaged from the master and reflect a
> current up-to-date state.

You are understanding perfectly. I was just pointing out that it is
not the only way to do things.

>
> I suppose the master space could always be used to "serve" a fresh
> reset copy of a space to a new user or group of users but then I'm
> not really sure what good that does in a lot of collaborative spaces.

It wouldn't have to be a fresh copy; it could reflect changes made by
users. The point is that the space doesn't need to consume
computational resources when no-one is using it.

> It works for a conference room type of situation where you might
> want a fresh, clean space each time you meet there and each group
> doesn't need to leave records of their collaborative work for other
> users to access when they are offline (or rather when their copies
> of the island are offline), but there are other times when you
> would probably want the changes users make to be persistent in
> something like a master copy (most people won't be able to leave
> their island running 24/7 unless it's on a server). If we join a
> space together and make some cool changes, then we both need to run
> resource hungry programs (maybe Second Life, lol) so we have to
> shut down our croquet islands on our PCs... how do our
> collaborators get to our work when our copies of the island are
> offline?

One possible way this could work is to have a serialized copy of the
space (could be the exact same snapshot format that a client uses to
get synced with other participants) stored on a server. A service on
the server listens for users who want to join the space, and when the
first one arrives it uses the serialized copy to start a "master
space" that the new participant then syncs from. Other participants
may come and go, and when the last one leaves, the master space can
take a snapshot of the current state and shut itself down. When
another participant tries to join, the process is repeated.

>
> Was the concept of a master copy intended to save the "last active
> state" of the island (changes recorded the last time copies were
> connected besides the master itself), does it just serve a "default
> image" of what the island looks like when everyone first arrives
> (no user collaborative changes?)... or can it do either depending
> on the application?

Right, either one.

> If no master copy is always online (typically on a server) then
> what have people been doing to sync croquet island user changes?

Croquet Collaborative has been running with a master copy always
running. Others have been looking at an approach similar to what I
described above.

>
> Is anyone storing persistent shared world/user data in a database
> (on a server) rather than constantly running a croquet island to be
> the master or island image? Couldn't each copy of an island write
> local copy changes to some kind of changelog process on the server
> that records the saved states (maybe even multiple diffs, like a
> wiki) in a central database so anyone initiating a new copy of an
> island could get the last known persistent data, even if their copy
> was presently the *only* copy of the island running online?

Sure, that's another option.

> The server wouldn't be sharing computation with croquet spaces but
> rather running checks and balances on the data updates sent from
> all of the collaborating copies so there would always be a live and
> "current" version of persistent island data. Even cooler would be
> if it was organized Gmail thread style so that you could look back
> at the past x images of the island and see who "changed" what (and
> be able to roll back changes if need be). Although that might be
> getting too wiki on the island concept. ;p
>
> Heh, sorry for all the questions. I'm just trying to wrap my head
> around how croquet was envisioned to handle persistence with full
> p2p and no central server managing the persistent bits.

Seems like you're doing a good job. The key point is that Croquet is
a platform, not a single application, and that there will hopefully
be a diverse ecosystem of different approaches. I have a personal
interest in exploring how other fully-distributed approaches (such as
distributed hash tables) can play a role; it's going to be interesting!

Josh

>
> Thanks for all the great info so far,
> Kelly
>
>
> With respect to running a "master space" (which, I should point out,
> is not a core Croquet concept... others have experimented with
> storing a description of a world on a server; the first person who
> tries to join the world creates the world from this description
> rather than syncing with an always-running island replica) on Linux,
> I think that pretty much any version of Fedora should work. The
> persistent copies of Croquet Collaborative islands run on FreeBSD,
> which is definitely a less common Squeak/Croquet platform. I would
> again recommend looking at the Croquet Collaborative codebase, which
> goes to some lengths to allow running a "headless" (no OpenAL/OpenGL)
> Croquet image; this has the dual benefits of reducing the
> computational load on the "server", and of reducing the dependencies
> you would otherwise have on a properly installed OpenAL and OpenGL.