Hi Andreas.

Interesting you should mention these topics! They are related to yet 
another problem I'm trying to tackle - version control with objects. 
That is, managing changes of state in distributed shared objects and 
being able to rollback to a previous state for security reasons (replica 
has been attacked) etc.

Right - firstly, I'll define an "Compound object" to be a "hard 
segment", or "group of objects with an explicit owner". Compound objects 
seem to have lots of potential; they are big enough to add features that 
would otherwise be considered too much overhead for single objects.

Features such as:

- Version control and Transaction control (i.e. the TeaTime stuff).

- Resource management. Compound objects can be assigned a certain amount 
of memory/storage, or a certain amount of CPU cycles / time / priority 
(compare: processes in an OS).

- Persistence to something other than the image. We can use relative 
references that are only valid within that compound object.

- Distribution and Replication. Messages going to a Compound object can 
be caught and used for replication. A compound object can belong to a 
particular group of computers and not be allowed to migrate or replicate 
out of that group.

- Security - private objects within a compound object not accessable 
from outside. Also, security meta-information can be added e.g. 
sensitivity of data ("do not migrate"), encryption keys, etc. 
Communication through an Interface could be possible (Squeak gets 
Interfaces!)

- More Security - A compound object could be a sandbox with it's own set 
of threads, own SystemDictionary etc.

- Performance meta-data - advanced stuff, like the recording of 
migration behavior as meta-data to optimize the replication strategy 
automatically. Really really hard, but possible. PhD topic anybody?

Andreas Raab wrote:

> I need to give a bit of background about the TeaTime model in Croquet for
> this. Croquet includes a fully time based model of execution, e.g., when you
> want to get work done you not only say WHAT to do but also WHEN it should be
> completed. The "when" part is captured by a TeaTime which has some
> "workload" associated with it. Each TeaTime has three states - "undecided",
> "committed", or "aborted". When it is created it starts out as undecided. If
> any particular workload associated with it completes before this TeaTime
> expires it turns into "committed". If it doesn't complete (or else is
> explicitly aborted) it becomes "aborted". One of the key properties of an
> aborted TeaTime is that it leaves no "traces behind", e.g., all of the
> changes which may have happened within objects will be undone.

Okay; Transactions and atomic operations. Nice.

> As you may imagine, having to track all the potential modifications
> manually, will be pretty inefficient (although we're going to start out that
> way in order to be able to understand the implications better). That made me
> think about making use of memory generations to capture all modifications
> done for all objects while some TeaTime is "completing" (e.g., delivering
> its workload) and then - in an atomic operation - be able to commit or abort
> all the changes at once; essentially retiring all of the modifications of
> simply have them reverted.

I'm not grokking this. By 'modifications' I assume you mean state 
changes. And by 'memory generations' I assume you mean taking snapshots 
of an object's state as it changes.

I don't understand the big picture here - what are you trying to 
achieve? Regular snapshots of a compound object's state so that a failed 
  computation can rollback and recommence? Why would you want to do that?

> If such a scheme works (which I have absolutely no idea about - much of it
> depends on "typical" properties of the workload associated with each
> TeaTime, its typical orderings as well as dependencies) you should get a
> really nice generational partitioning of your objects. How well this
> translates into replicating object clusters I am not sure but keep in mind
> that Croquet is a fully distributed system and as such my hope is that it
> may work *extremely* well in the TeaTime-based environment that Croquet
> provides.

I am quite impatiently waiting for Croquet to be released so I can pull 
it apart and see how you guys do the distribution! I've seen videos of 
guys playing a kid's version of Quake, but without guns :-) and somebody 
mentions that all objects are distributed.

Michael.