Ralph Johnson <johnson(a)cs.uiuc.edu> wrote:
Here are my current plans. Any comments?
Everything will be stored in files. It will be very portable. It will be
fast. It will be robust. You can edit all the text files safely.
A SmallWiki folder is a directory. It has one directory called resources
and one called pages. A page is stored as a text file in the "page"
directory. A resource is stored as a binary file in the "resources"
directory. A folder will probably have other files in its directory. If we
make new kinds of structures, we can make new subdirectories.
Each new version of a page gets added to the end of the file. Each delta
has a timestamp, the author, maybe the version number, and the data. A
timestamp line starts with T, an author line with A, the version number with
V, and the data lines with D. The delta ends with a line that starts with
E. Lines end with one of a set of end of line characters, including CR and
LF. Blank lines are ignored. This should make it so we don't care about
the end-of-line rules of the creator of the file, so it should be easy to
more from Unix to Windows.
Make it easier to retrieve the current version. Why not store the
current version in its own file, and the history in a second? I'd
expect reads to dominate writes.
Some version control systems have taken this approach.
Resources are only stored in the file system. Folders
and pages are stored
in the image. The disk version of the folders and pages are only read when
the image is starting up. Otherwise, they are only written to, not read.
It should be easy to write the storage manage to handle new pages, new
folder, page edits, and resources. However, I am worried about renames.
Renaming a file is easy. But don't we also have to change all the files
that are in existing pages?
Absolutely. With this kind of approach, you've got to traverse the
entire
tree, rewriting references as needed.
This is part of the reason I was leaning to a database approach, and
maintaining dependency links. On the other hand, renames shouldn't
be that common, and your approach's simpler.
Another reason I was thinking about database storage, is that I'd
like to support placing objects on pages, and treating pages as
collections of articles and objects. An object might be a query
that retrieves a set of objects to form the page. This is all
a significant step beyond a traditional Wiki, though.
-dms