Draft for wiki class

We have all the parts of the wiki, expect the most important one: the wiki. The wiki object can manage the wiki state and keep the state in memory and on disk.

Parts of a wiki

The wiki is the complete model object of a wiki. You would use it to get and set data.

• farm - the wiki parent
• config object - based on the configuration file, cached in memory
• plugins - dict of plugins installed in the wiki data plugins directory
• pages - dict of page objects in the wiki
• groups - dict of group objects used for acl
• dicts - dict of dict objects used for custom translations
• templates - dict of template pages
• users - dict of user objects
• log - log events to log files
• notifier - notify objects on wiki events

Update State On Change

Today we generate the state of the wiki for each request.

For example, when we search, we go and list the directories on disk, checking that each page has a revision file pointed by its current file. Then if we search again one minute later we go again and list the directories on disk, checking that each page has a revision file pointed by its current file. Then if we search again 5 minutes later we go again and list the directories on disk, checking that each page has a revision file pointed by its current file. Then ...

I hope you go the point We do not need to do this again and again. The state of the wiki did not changed - no page was created, renamed or deleted in those minutes, or hours.

What we need to do is change the wiki state on change:

• When a dict page is created (saved) the wiki update its dicts object with the data from the dict page
• When a page is saved, deleted or renamed the wiki update its pages list
• When a user is created, the wiki update its user list

Now when we ask the wiki if page exists, its a simple dict lookup.

Load on demand

Since we should work with CGI, I don't know if its fast enough to load and dump the full wiki object from a pickle for each request. maybe we need to load a minimal fragment of the wiki, like the config object, as we can not run without it, then load stuff from disk when needed, for example, if we just visit a page, we don't need the complete page list, maybe its faster to check if certain pages exists then to load a pickle with 3000 pages.

Pages dict

Keeping pages dict using page names as key and page object as value might need too much memory and too slow to load or dump to a pickle. Maybe we can keep a dict of pagename: None, and create the page objects on demand. So page.exists will be pagename in wiki.pages. You will get a page object by using wiki.pages[pagename], which will use custom __getitem__ method to create the page object.

Notifier

Users can subscribe to events - page created, renamed, deleted, modified, user created etc. The notifier can handle sending mail/instant messsages whatever to those users.

The notifier can also handle notifications to other objects in the system. For example, if page A link to page B, it would like to know when page B is deleted or renamed. So page A subscribe to PageDidRename, PageDidDelete events for page B. When page page B is renamed, the notifier will get a message, and notify all other pages/users/whatever objects that subscribed to these events.

Read more in EventSystem.