My plans for persistence in SmallWiki

[Lukas Renggli]

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.  
> If we
> 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:

	/_Folder_
		SubFolder1
		SubFolder2
	/_Page_
		Page1
		Page2
	/_Resource_
		Resource2
	/_Glossary_
		Entry2

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 
as file-extension:

	SubFolder1.Folder
	SubFolder2.Folder
	Page1.Page
	Page2.Page
	Resource2.Resource
	Entry2.Glossary

> 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.

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 
> renames.
> Renaming a file is easy.  But don't we also have to change all the 
> files
> 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 
> have to
> write something to build up a wiki from a file system, and will have 
> to make
> 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.

Cheers,
Lukas

-- 
Lukas Renggli
http://renggli.freezope.org