Ralph Johnson wrote:
>External SIXX persistance exists.
I haven't looked at it yet, but I am skeptical. Do you think
it will do what I want? XML is just barely human readable.
It tends to be slow. It is OK for a least common denominator,
but you can almost always do better.
I haven't looked at the sixx stuff since it was removed from the base,
but I don't think it would work well. Essentially, it would save out
everything every X seconds. If you had a power failure you could loose
edits. Also, since it was saving everything, it would be quite slow --
you don't need to save everything for one edited page.
I have built a storage mechanism that stores everything in two files.
Whenever a page is edited, both files are updated. One file contains a
one line description of a wiki item. This line then indexes into the
other file for the full text. For example, the first file would look like:
~1 0 0 559
~2 0 559 1189
~3 0 1189 3605
~4 0 3605 6611
~5 0 6611 7862
Lines that begin with + are new wiki items (page/folder/resource). Lines
that begin with ~ are edits -- the last two numbers are the indices into
the other file.
The detail is stored in the other file. For example, here's the detail
for the "~1 0 0 559" record:
Data: Welcome to SmallWiki, a new Wiki-Wiki implementation in Smalltalk.
Below you can find a list with the contents of the root folder of this
Wiki. By default this list is generated automatically, but you might
replace it with your own welcome-message and page-index.
!Contents of this Site
[ "If you are not logged-in as administrator, please remove everything
between the square-brackets before saving the page!"
structure renderListOfChildrenOn: html ]
When the wiki is restarted, it scans the description file and loads the
latest version of each page/folder/resource. Previous versions are
loaded only when they are accessed. It takes less than 20 seconds for
#Smalltalk to load my clone of the VW wiki from November -- ~830 pages &
With this scheme you can edit the description file, but you really can't
edit the detail file. You can append a new item at the end of the file,
but if you edit in the middle you will likely mess up the indices.
BTW, this scheme doesn't address the problem of resources being stored
in memory. For example, if some idiot uploads his 50MB video to your
server, it will increase the size of the running program by 50MB. Large
resources shouldn't be held in memory -- they should be stored directly