What does NSK stand for?
"We interrupt 'Battle Of The Network Space Krackens' to bring you this special report."
- A simple Wiki for my personal use. Focus on formatting and layout.
- A simple Wiki/CMS for the family web site. Focus on authentication/authorisation and flexibility.
- A moderately-capable Wiki/CMS for use on the internet.
- World conquest!
- A moderately advanced formatter.
- Support for images.
- A fairly simple templating system.
- Simple user and group accounts (not tested much).
- RSS and Atom feeds of resource histories and site-wide changes.
- IPv6 capable.
The current stable version of NSK has been tagged â0.5â. It has been running my personal Wiki site for over a year now and this has largely driven my development of NSK.
There are a few things that need to be finished on the 0.5 branch, but for the most part it is âdoneâ. I am currently focusing on the â0.6â branch.
Work on version 0.9 has stalled due to its ambitious goals. I have instead decided to âback-portâ its (partially completed) features into interim releases.
The goal for version 0.6 is to back-port the PostgreSQL backend. This will improve performance and allow various features expected of a modern Wiki. For example, looking at the âcontributionsâ of a single user on the Subversion backend would have involved potentially looking through every revision in the repository, a very expensive operation. Doing the same on a relational database is a simple table lookup.
Other features will be back-ported in versions 0.7 and 0.8.
- Improve speed and efficiency
- Become much more of a CMS, rather than a simple Wiki for writing stuff
- Move a lot of functionality and content from the NSK codebase into plugins or the sites themselves
- Switch to a database backend using PostgreSQL.
- Add âscriptâ resources which can execute Perl code in a sandbox e.g like the Special: pages on MediaWiki but as resources that can be edited online (presumably only by admins).
- URLs will be simplified, thanks in part to the âscriptâ resources. The âactionâ part of the URL before the resource name will be removed. Core actions will be handled by an âactionâ parameter (either GET or POST). Other actions will be handled by scripts e.g history, diffs, contributions, etc.
- Add âviewsâ to namespaces - templates that allow heavy customisation of the presentation of a group of resources. Discussion pages will be implemented with these, removing some hard-coded logic.
- Namespaces can be shared between multiple sites, with different views for each. This could be used for distinguishing between internal/external web sites, or having multilingual information.
- Generate an XML DOM tree in the parser and use XSL templates to transform the content for various outputs e.g (X)HTML, XML (with client-side XSLT), plain text, printable PostScript or PDF via LaTeX and/or XSL-FO.
- Add hooks for plugins at various places. This could be used to move a lot of the âprettifyingâ code out of the Wiki parser. It could also be used to handle different âmediaâ resources e.g scaling (and thumbnailing) of images, videos, etc.
- Create a purely state-based Wiki parser that can potentially recurse into documents/templates of different formats e.g HTML, MediaWiki, Trac, etc.