On Wed, 28 Aug 2002, Ned Konz wrote:

> * Changes to business objects (that is, whatever you're trying to
> trying to persist/replicate) must be represented by serializable
> command objects (MessageSend, etc.).
>
> * These commands are atomic transactions.
>
> * The commands are passed to a method of the business object (probably
> added as an extension in Object) that knows about the persistence
> scheme. This method serializes the commands and appends them to a log
> file (see below). Then it executes the commands (or maybe it's the
> other way around, I'm not sure).

Actually, in the implementations I've seen, these commands are sent to a
central manager, not to individual business objects - otherwise, when you
were logging the command, you would have to somehow log which object it
was sent to as well.  This is the main problem I see with this scheme -
that manager object becomes a massive bottleneck in your design, and to
keep all those commands easily serializable, they need to refer to all of
your business objects through some sort of primary key scheme rather than
through direct references.

If you kept a weak mapping between business objects and unique ids, then
you could probably avoid these problems.  You'd serialize and assign an id
to an object the first time it appeared in a command (either as receiver
or argument), and refer to it by the id in all future logs.

Josh Flowers did indeed do some work on a Squeak port; it was posted to
the Seaside list a while back:

http://lists.squeakfoundation.org/pipermail/seaside/2002-March/000057.html