The Project site can be found at http://saffron.caret.cam.ac.uk/projects/sakai-rwiki/
note: This site is rebuilt by Gump from our cvs head at 0400 GMT everyday.
Currently at RC1 for Sakai 2.x
For the moment, releases are RWiki Releases
Sakai Wiki Tool is intended to support Wiki functionality within Sakai, tightly integrated with Sakai services. This page is not talking about this Wiki (eg Sakaipedia)
We have a list of Sakai Wiki Tool Use Cases that have informed this tool, please add to this list if you want to influence how it works.
Source code is available in svn https://saffron.caret.cam.ac.uk/svn/projects/rwiki see http://saffron.caret.cam.ac.uk for information on how to get access to the repository. From time to time there will also be source code releases at http://saffron.caret.cam.ac.uk/downloads/
A prototype version is available for Sakai 1.5 at cvs://cvs.sakaiproject.org/contrib/RWiki.
Their is also another wiki tool cvs://cvs.sakaiproject.org/XWiki which is a port of the XWiki wiki. This XWiki tool is not under active development (see below for more information)
Neither of these versions should be considered production ready.
The RWiki tool contains a Wiki Rendering Service and an Wiki Tool. The Wiki Rendering Sevice is a Spring component that may be used by other tools to render wiki markup into fragments of html. The Wiki Tool uses this service to render its wiki markup.
Wiki Rendering Service
The Wiki Rendering service uses the Radeox wiki engine to deliver Wiki Rendering. It uses the Radeox engine and hence has the same markup as mainstream wiki tool like SnipSnap. It has been implemented in such a way as to allow and Radeox based wiki macro to be used. (eg Radeox RSS Aggregator)
The Wiki tool integrates tightly with User, Site, Realm and resources services in Sakai 1.5.
It uses User service to determine the current user for page ownership.
It uses Realm for permissions within the current site.
It uses site to create a default wiki space into which a user adds pages.
It may reference resources within resources too for inclusion into wiki pages ( eg images )
Features italic means future bold means new
- Wiki Markup
- Radeox wiki markup (as in SnipSnap)
- Radeox Macros ( eg image, rss etc) extensible
- Sakai integration
- knows about user, realm and site.
- will access sakai resources
- Spaces, like Snips in SnipSnap
- automatic default space is created named by SiteID
- all pages with no specific space id, are assumed to be in the same space as the parent page
- Subspaces may be generated
- Cross worksite spaces may be generated
- pages may be shared between worksites.
- Space persmissions derived from Site Realms and Roles.
- Addition per page permissions on each page.
- Allows complete public anon view of pages if selected.
- Sakai Tool integration
- Resources may be included into pages (images are rendered)
- Rendered output of any tool in work site ( to be implemented)
- Page Versioning and History
- Wiki pages get versioned automatically.
- There are pages to allow one to view the history of edits to a page and differences between them
- Page Differences are displayed as colourised diffs
- There should be mechanisms in place to inform editors if they are about to overwrite unseen changes. Full optimistic locking with long lived editing sessions.
- Wikipage navigation
- Current tool generates breadcrumbs as a stack of pages you have recently seen. A page can only appear once in this list, and hence if you go back to a previous page it is removed from the list and re-inserted at the end.
- Breadcrumbs contain links to previous searches.
- Searches are performed on page name and on full-text search.
- Searches should be restricted to only pages that you can see.
- Maths Support
- There is a Maths macro that allows you to enter Tex. A plugin java script library renders the Tex in the browser on view.
- Comment Support
- We would like to scope the requirements for adding comment support. There are several issues to be resolved:
- What sort of permission structure should be added?
- Do we want comments on comments?
- Any other thoughts?
Enhancements and future bug-fixes
- Improving the performance of History
- In our current model we use an attached List of RWikiHistoryObjects for storing the history of a page.
- This link is currently a hard-link and thus when the number of revisions gets large there will be a definite slow down in performance.
- There are two options to solve this problem:
- Use Lazy Initialization and inherit all of the difficulties associated with that
- Separate the link, and break ORM.