[Etoys] Projects and Journal
bert at freudenbergs.de
Sat Jul 21 12:54:19 EDT 2007
No response, yet?!
This will fundamentally influence the user experience on the OLPC.
The Journal's notion of "keeping" is actually pretty much precisely
what a project is in etoys. However, due to the design of the journal
and the security compartmentalization we will not be able to serve
multiple projects in one VM and image. Opening a new project will
only be possible by starting a new VM and image. Switching between
projects will not be a cheap operation.
So in contrast to what I wrote below there is a one-to-one
relationship between activity instances and journal-entries. This
wasn't clear to me until yesterday. Currently it is possible to
create multiple journal entries from one activity instance, but
actually the actual model would probably be that creating an object
and launching a fresh activity instance is one and the same operation.
Other activities are far from realizing the intended user experience,
which of course would include that on resuming the UI returns to the
exact same state it was when it was interrupted. We are in a much
better position for this because that's how Smalltalk always worked
(I wonder where they got the idea ...). Still, since the reality of
current Squeak implementation clashes enormously with the reality of
Bitfrost and Sugar, we'll have to come up with better ideas for
I'd really like to discuss this face-to-face but given the time
pressure, email will have to do ...
- Bert -
On Jul 12, 2007, at 14:58 , Bert Freudenberg wrote:
> We need to think about the user experience of Etoys projects on the
> XO. If someone is not yet familiar with the idea of the Journal,
> please read
> Projects are the fundamental unit of work in Etoys. So we want to
> keep them in the Journal and resume them. However, that should be
> mostly automatic, in contrast to the explicit save dialogs we use
> on regular PCs. Also, we cannot save the whole image. I don't think
> kids work the same with projects as Alan does. And I'm not sure if
> Alan ever worked in the browser version of etoys, I only know his
> images which have a gazillion projects preloaded ...
> But, ideally the user experience should be *as if* the image was
> indeed snapshot continuously. Here's an idea I came up together
> with Michael:
> We always ever have only one single project loaded at a time. This
> is good for limited RAM. Before entering a different project, we
> store the current one in the Journal. Then after we are in the new
> project, purge from memory the old one.
> On startup, we might want to load the latest project in the
> Journal. This would be analog to "image saving".
> I am working on saving to / retrieving from the Journal. This will
> hook into the old project saving logic for now. But I think
> something along the lines above is needed, too. As for performance,
> with the better book morph support we do have now, perhaps having a
> thread of projects isn't really that important?
> Some more thoughts below ...
> The Journal will keep each version of the file. To keep down on
> disk size, it is supposed to only store differences between
> versions. That means we need to store projects in a way that
> enables diffing. A textual representation for projects helps with
> this, but if we are going to compress it, we need to take special
> care (for example, like the "rsyncable" gzip option http://
> We might also want to know if actually something changed in a
> project, that is, wether we need to save it or not. Might be hard.
> Meta data
> For finding projects in the Journal we will want to add some
> keywords. That could be strings the kid put into the project or
> player names (if not automatically generated), maybe even variable
> names - everything someone typed might be useful for retrieving the
> - Bert -
More information about the Etoys