[Use the image+changes file as store for wiki-like thing]
Well, lately I've noticed I'm not very happy with Squeaks recovery
model, that is, when an image dies, it takes too much work to separate
the changes I wrote and value from the stacks of code various packages
insert into my changes file (which I would reinstall anyway). 

I'm also not very happy with the mobility of code between images when I
choose to switch - again this requires digging around changesets and
changesfiles, explicitly filing things out, filing them in the new
image... awkward.

I think that Smalltalk got a lot of things right about handling code -
* Almost everything you do gets saved, so little is lost (mostly context
for doits)
* Easily visible

However, these things should not be local to the image, and shouldn't be
specific to code. That is, everything I write - a mail in Celeste, notes
in a workspace, code - should be saved to an external repository all the
time, and that repository should not be dependent on the specific image,
and browsing through it should not be as painful as looking at the
changes file is. 

Anyway, that's just my general opinion on things. Specifically it means
that I definitely don't want the usual recovery model to my personal
information. Swikis fulfill the requirements above, so I put my personal
information there. But Mozilla/Scamper as editors really do stink.

For the case of code, I am hoping we'll get the advantages above from
Monticello.

[Using the class as the model and Browser as UI for personal
information]
Yes, I like that idea better, I've thought about it in the context of
papers - that it would be nice to write papers in a browser, overriding
classCompiler so that methods are treated appropriately (for example,
converted to LaTeX and passed to the native tools for rendering when I
ask for it).

Daniel

Lex Spoon <lex at cc.gatech.edu> wrote:
> Daniel Vainsencher <danielv at netvision.net.il> wrote:
> > Hi, I've been thinking about making a simple swiki editor. The idea is
> > to base it on the StarBrowser, so that one can traverse links using the
> > tree, and view and edit pages in the editor pane, which would be a
> > lightly tailored text editing pane.
> 
> Daniel, it would also be possible to do this the other way around: embed
> a wiki directly in the image.  This would be excellent for
> documentation.  Call it iwiki, perhaps, for "internal wiki".
> 
> There are a bunch of little things that would need to happen, for this
> to be smooth:
> 
> 	1.  Each image needs to have an iwiki in it.
> 
> 	2.  There is a new alt-6 option for likning to wiki pages.
> 
> 	3.  The URL machinery can handle iwiki://  URL's, so that you can use
> this from Scamper.
> 
> 	4.  (Hardest part) The changes sorter understands iwiki pages, and can
> file them in and out.
> 
> Incidentally, you can almost hack all of this by using class methods
> that only have comments in them.  It's a bit clunky, however....
> 
> 
> Lex