Some thoughts and additions:
A SmallWiki folder is a directory.
There are several extentsions available that subclass from folder (e.g.
Photo Folder), they should be handled properly as well.
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.
make new kinds of structures, we can make new subdirectories.
I don't understand why a pages and resources are handled differently
(pages are put into the directory, resources get an extra directory).
Maybe pages and folders should be put into some artificial folders
(e.g. _classname_) as well, so that there is more of an uniformity:
Or more simple (shouldn't we do it as simple as possible?) one could
put all the data into the same directory and to put the type/class-name
Each new version of a page gets added to the end of
the file. Each
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
V, and the data lines with D. The delta ends with a line that starts
E. Lines end with one of a set of end of line characters, including
LF. Blank lines are ignored. This should make it so we don't care
the end-of-line rules of the creator of the file, so it should be easy
more from Unix to Windows.
Personally, I prefer to have human-readable tags (like the ones
suggested by John Brant). Also name-clashes from different extensions
are less probably if proper names are used.
It should be easy to write the storage manage to
handle new pages, new
folder, page edits, and resources. However, I am worried about
Renaming a file is easy. But don't we also have to change all the
that are in existing pages?
Yes, this is a problem. In the very beginning of SmallWiki I used
weak-object-references to represent links, so this was very cool:
Whenever a page got renamed, moved or deleted the whole wiki-composite
was kept in a well defined state automatically and all the links were
still valid (nil, if the target has been deleted).
Unfortunately this approach lead to problems with platform portability
and also storing the structure was more difficult. So I went back to
have strings representing the references, what is the worst thing in
SmallWiki in my opinion. Currently I have no better solution: when
renaming a page I have to walk over the whole wiki using a visitor and
change all the strings, however this works only for leave nodes :(
In addition to writing a storage manager to update
these files, I'll
write something to build up a wiki from a file system, and will have
proxies for resources so they don't have to be in the image.
There are lots of visitors walking over the whole structure (e.g. to
create the rss-feed, the history, the search engine, ....) so this
should be efficiently possible.