history memory control

[Craig Latta]

Hi Norbert--

 > I don't want to deal with two things (subject and history). It reads a
 > lot like I need to start two different images to be able to start
 > working. Are there ideas how to hide the fact that there are two
 > things involved?

      Yes indeed. The subject memory starts the history memory (via the
OSProcess plugin), and manages its run state afterward, so the developer
need never think about it.

 > Or is there even the possibility to have the history memory and the
 > subject memory in one thing?

      You could run both memories at once with Hydra (as David Pennell 
suggests), but I'm not yet sure what effect it could have on crash 
recovery. If one memory managed to crash Hydra, could another one go 
down at an inopportune state?.

 > Don't get me wrong I really like the idea to have these separated. But
 > I want to separate them later not at first. I like to edit my history
 > (and also remove versions).

      You can do that from the tools running in the subject memory, but 
no mention need be made of the history memory per se.

 > Is there a definition of a fallback behaviour of the history memory if
 > a version is missing?

      How would that happen? The only ways I can imagine so far would 
also take out the entire history memory, and probably the subject memory 
too (i.e., people should still run backups of their storage).


      thanks!

-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]