[squeak-dev] Re: second call for feedback on Naiad design
craig at netjam.org
Sun Jan 18 23:49:05 UTC 2009
Thanks for the feedback!
> I'm not so concerned about absolute size, since disk is cheap. But I
> wonder about the time/CPU it will take to snapshot the whole image
> each time you edit a method or evaluate something in the workspace
> (DoIts are recorded in the history image, right?). Appending to a
> file is an O(1) operation, but snapshotting an image is O(n), where n
> is the total number of updates.
My claim here is that the added expense is worthwhile, given the
greater functionality of objects over change-file chunks. Also, the
developer may continue to work while the snapshots occur; the system
> Another concern is data integrity. What happens if your machine
> crashes while you're snapshotting?
The system doesn't delete the previous history snapshot until the
next one is successfully written (some would argue that all snapshots
should work this way). One could also host the subject and history
memories on separate machines. One could also maintain a history memory
*and* a changes file (and perhaps snapshot the history memory less often).
> If you're simply appending to a .changes file, there's no problem.
It seems to me that the capacity for data loss is the same in both
cases (the most recent change only, unless the storage devices on
machine hosting the history memory or changes file are wiped out also).
> Of course, this is surmountable, but the solution will be more
> complicated than a changes file.
Well, of course the history memory scheme is already more
complicated than a changes file, but again I claim it's worthwhile. :)
> > I imagine the history memory will have various utilities, like:
> > - dumping all the compiled method info, because the subject memory
> > will always have a compiler
> > - dumping all the method source, because the subject memory will
> > never have a compiler :)
> This level of flexibility worries me a bit. It's cool that the model
> supports these types of uses, but if it's going to replace the
> .changes file, it needs to be simple and stable.
> I realize that this is a bit unfair, because you're talking about the
> interesting characteristics of the model, not focusing on how to make
> the transition from .changes to Naiad. At some point, though, we'll
> have to have that conversation.
Sure, I think now is a great time to discuss that. Of course, it's
also fair to discuss the shortcomings of the changes file scheme. It may
be simple and stable, but I also think its utility is unacceptably low.
I strongly suspect the changes file scheme is an anachronism, primarily
driven by the costs and availabilities of processor cycles, disk space,
and network bandwidth in the 1970s. But even if the original designers
thought it was a great idea and would do it the same way now, I still
find it a hindrance. :)
While I have the same concerns you do, the status quo is so bad
that I want to pursue this design.
> > - storing its less-frequently-accessed editions in one or more
> > separate history memories, which spend most of their time as
> > suspended snapshot files, but which can be activated when
> > necessary. Remote message-sending is a fundamental part of
> > Spoon; there's no inherent reason why the history memory can't be a
> > federation of history memories instead.
> > Of course, one might decide to put editions in another object
> > database at any point instead (e.g., Magma or Gemstone). I just
> > want to provide something that provides the bare minimum
> > functionality "out of the box".
> Good to see the focus on simplicity. But what is the use-case driving
> your definition of "bare minimum functionality"? Is it a prototype for
> people to gain exposure to Naiad? Is it something that can replace
> .changes for Joe Squeaker's day-to-day use?
The latter. Indeed, I've been trying to get people to tell me
their desired use cases.
More information about the Squeak-dev