Introduction

Please note, this document is in draft and constantly evolving. The current release in 2.0. The next release will be 2.1. You should look to JIRA to see which of the features in the roadmap will be in the 2.1 release.
1.5 Requirements

Cut and paste required
Features

1.5 Release Feature List

• 1. Wiki Markup
  • 1.1. Radeox wiki markup (as in SnipSnap)
  • 1.2. Radeox Macros ( eg image, rss etc) extensible
• 2. Sakai integration
  • 2.1. knows about user, realm and site.
  • 2.2. will access sakai resources
• 3. Spaces, like Snips in SnipSnap
  • 3.1. automatic default space is created named by SiteID
  • 3.2. all pages with no specific space id, are assumed to be in the same space as the parent page
  • 3.3. Subspaces may be generated
  • 3.4. Cross worksite spaces may be generated
  • 3.5. pages may be shared between worksites.
• 4. Permissions
  • 4.1. Space persmissions derived from Site Realms and Roles.
  • 4.2. Addition per page permissions on each page.
  • 4.3. Allows complete public anon view of pages if selected.
• 5. Sakai Tool integration
  • 5.1. Resources may be included into pages (images are rendered)
  • 5.2. Rendered output of any tool in work site ( to be implemented)
• 6. Wikipage navigation
  • 6.1. 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.
  • 6.2. Breadcrumbs contain links to previous searches.
  • 6.3. Searches are performed on page name and on full-text search.
  • 6.4. Searches should be restricted to only pages that you can see.

2.0 Requirements

This section outlines the requirements that were addressed by the 2.0 release.
Sakai 2.0.x

Must use a Sakai 2.0.x build mechanism and deploy into sakai 2.0.0 or 2.0.1.
Architecture

The archtetecture needs to be reviewed to achieve a lower memory overhead with a higher page serving performance. Pages should typically be served in < 50ms on a low end PowerBook (eg 1.3GHz G4). The architecture should be structured in a service oriented way to eliminate heavy object consumption as part of the request cycle.
Markup

The implemented markup is based on Radeox, which a simplified version of the markup found in SnipSnap. Most of the complex macros seen in SnipSnap are not present (eg Blogs). All of the standard markup (linking and formatting) is present.
Optimistic Locking

The aim of optimistic locking is to allow users to edit a page without unduley risking overwriting someone elses work. If user A starts editing a page, then user B edits and saves the same page, user A, when they save their changes could overwrite user B's edits. With optimistic locking user A is notified that user B has made changes whilst user A was editing, and user A get the option to decide what action to take.

Optimistic Locking has been achieved by maintaining a version field with each page, however we are not relying on the optimistic locking features of Hibernate to determine when an optimistic lock has been violated. This is performed by the code and the user is given the opertunity to either overwrite the interceeding content or accept that content. We found using Hibernates own optimistic locking mechanisms did not give the user enough control over the operation.
Version Control

As pages are edited, each edit results in a new version of the page. The time of the edit and its entire content are stored in the database. We are not using an RCS based version control.
Diff View

With Version Control a Diff view is required. The Diff view should allow the user to view the differences between two versions, that the user can select. It should enable the user to clearly identify what has changed between to the two versions. We are not, at this stage looking to see a complete change history in a single page (as with Track Changes in Microsoft Word) as this is probably to complicated to implement at this stage.
Preview

To avoid forcing he user to save their changes just to see if they have formatted the changes correctly we need to have a preview function on the edit page. This should maintain the edit state of the edit page and without saving the edits, allow the user to preview their wiki markup as it will appear on the final page. The user should not be asked to navigate back and forward to see the preview.
Attachement Support

Each RWiki space within the worksite should manage its own subfolder in sakai resources that contains attachments. RWiki should reuse the sakai resources functionality to enable a use to upload content on the page. It should provide a list of uploaded the contents, for that page, on the pages (e.g. there are 5 attachments to this page). Should investigate what happens when a resource is moved, and how be might handle it. Is their an event in Resources we can watch ?
Image Support

It should be possible to reference any file in resources inside RWiki. If the source can be rendered as an image, a img tag should be used, otherwise a link should be used. This is probably implemented in the properties file that implements the mark-up.
Maths Support

It should be possible to insert Latex mark-up into the page (suitably delimited). Where that mark-up us present, a plug-in should use a Latex-rendering engine to emit wither MathML or a gif to represent the math, see MediaWiki for examples.
Prepopulated Pages

The existing blank pages that are deployed on install need to be expanded. Their should be some basic structure setup and some help on the available mark-up.
2.0 Release Feature List

• 1. Move to Sakai 2.0 done
• 2. Rewrite request archetecture done
• 3. Check functionality with Sakai 1.5 postponed pending demand
• 4. Implement version control done
• 5. Implement complete robust optimistic locking done
• 6. Implement usable preview support done
• 7. QA Rewritten archetecture done
• 8. Implement Visual Diff of versions done
• 9. Implement Prepopulated pages, sidebars, help, howto's done
• 10. Implement Export support postponed pending more requirements
  • 10.1. Needs to take account of Helpers and Archiving
• 11. Review markup done
• 12. Implement attachement support postponed, using Sakai Resources
  • 12.1. Need to make it easier to put attachements in
• 13. Implement Navigation support done
• 14. Implement Image Support done
• 15. Reskin UI layout done
• 16. Implement Maths Support done

Future Requirements

• 1. Comment Support
  • 1.1 We would like to scope the requirements for adding comment support. There are several issues to be resolved:
    • 1.1.1 What sort of permission structure should be added?
    • 1.1.2. Do we want comments on comments?
    • 1.1.3. Any other thoughts?

Roadmap Requirements

• 1. Performance of History
• 2. Comments
• 3. Event integration
• 4. Navigation Persistance
• 5. RSS feed of recent changes
• 6. Helpers
• 7. Integration of Events into Courier
• * 8. Rename a page needs discussion
  9. Spelling

Improving the performance of History

• 1. In our current model we use an attached List of RWikiHistoryObjects for storing the history of a page.
• 2. 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.
• 3. There are two options to solve this problem:
  • 3.1. Use Lazy Initialization and inherit all of the difficulties associated with that
  • 3.2. Separate the link, and break ORM.

Comments

To make the wiki usefull in a educational environment, we would need comments on a page. This is probably a sequence of wiki pages, probably with a different set of permissions, that a associated with the main page.
Event Integration

RWiki should register events, navigation from page to page, when an edit is started, every transaction with RWiki should cause an event to register.
Navigation Persistance

At the moment there is no navigational persistance. When you switch between tools, you loose the state of the RWiki tool. We want to provide Navigational persistance without locking anything. There are a few options.

• 1. Client Side
  • 1.1. The tools stores its state in client side cookies so that when the user returns to the start page, the tool moves to the last state page, by refresshing the page. This is a minimal impact approach.... however it will only work relyably for gets. If applied to POSTs and editing page, we probably will not be able to store all state in cookies.
• 2. Server Side
  • 2.1. As we move via each page we maintain a client state in the server session. This means that all copies of the Wiki tool within the Same worksite, Same session are tied, when on the home page. It may be possible to track new Windows, same session, and/or new tab same session. In addition we have to track editing content, so, periodically as the use types, their state is saved to the server. Then when the switch tools/worksite and come back to the edit window, their edits are not lost.
• 3. Issues
  • 3.1. Both mechanisms must track windows in the same session and not tie them together.
  • 3.2. Both mechanisms must only restore state on the Home page, since that is the one where state will be reconstituted from.
  • 3.3. Should consider enclosed view state as exists in .NET (only as a informative model, not as an example of good implementation)

RSS feed

Feed of recient changes as RSS, but also other features. If these events are RWiki specific they should be RWiki standalone, otherwise they should integrate with Sakai Events.

Helpers

At the moment we have a rendering service for RWiki. We also need to expose the pages of the wiki as undecorated content so that other tools can use the content. If RWiki becomes fragment capable via its helper, then its content will become available via JSR-168 provider. That is why this is important.

Courier

With events in place, these should flow to the UI, so that a user is notified when annother user starts to edit a page. This might include all activities in the wiki space for the worksite.

Rename page

Need to rename a page, however this creates and issue for references. Perhapse we need a permlink to avoid external 404's

Spelling

• 1. A non intrusive spell checker that cheked spelling as typing (using ajax), as you might have noticed, my speling is bad!