||This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: NOT IMPLEMENTED. Implementation of a generic plugin architecture is still a very difficult topic from both a scope and implementation standpoint.
This document captures requirements and design discussions for a JAMWiki plugin interface.
A number of Feature Requests are items that could be implemented via a plugin architecture. A more specific discussion took place at Tech comments:addon. My personal preference would be that a plugin architecture would follow these principles:
- Easy to use. Allow users to drop a JAR file into their classpath and perhaps update one configuration setting (preferably via a web interface) and the plugin can then register itself and expose configuration and other features. Something like a [[Special:Plugins]] page could be created to manage installed plugins.
- As non-intrusive as possible. I'd like to see a well-defined plugin interface, possibly with sub-interfaces, so that plugins can register themselves for execution without the need to massively modify existing code. Use cases would probably be helpful in determining how this could be done:
- Captcha for user registration and/or editing.
- Spam filter (both web-based administration and executing against edit content).
- User tools, such as the Mediawiki calendar.
- I'd prefer that any initial implementation focused on converting existing functionality rather than adding new functionality, so (for example) the spam filter could be re-implemented as a plugin.
There are a number of frameworks that offer plugin support, but since JAMWiki utilizes Spring and J2EE I would prefer to use the tools available in that structure rather than introducing anything new - a Google Search reveals several techniques.
- Also note that I'm thinking there would be a difference between plugins and extensions to the parser - the parser code is very different from the rest of the JAMWiki code, and I would prefer to keep these two areas separate. -- Ryan • (comments) • 31-Jul-2010 11:00 PDT
I've found an interesting thesis about developing an OSGi module driven plugin interface for JAMWiki:
Support for Integrity Module as Plug-in in an Existing Wiki
This could be a valid solution proposal.
Greetings, Peter Siegel
- Were the referenced code changes also made available online? I remember these guys asking some questions several months ago, but there wasn't any follow-up. I didn't read the entire 152 pages tonight, but will probably do so at some point in the future and would be interested in the code changes made. Thanks for pointing this paper out. -- Ryan • (comments) • 20-Mar-2012 19:47 PDT
while strolling around in the www pages I've found another scientific work that extends JAMWiki as its software base.
Please have a look at Secure Wiki System - A plugin-based solution to wiki security.
This thesis relies upon the experiences documented in the above mentioned work describing a prototype with an OSGi-implementation. The changes made by the prototype implementation extend the JamWiki functionality by adding secure wiki model functionality.
The document is written by Kasper Lindberg, maybe you'd like to contact him.
... and some code can be found here.
By the way, I like your JAMWiki that is easier to install and maintain than MediaWiki. Thank you very much for a good job!
Greetings, Peter Siegel
- Thanks for the pointer - I've downloaded the PDF and will read through it when I get a chance. Unfortunately life events have kept me from doing as much JAMWiki development as I'd like lately, but hopefully a plugin architecture can be further developed in one of the upcoming release cycles - I know it's something a lot of people would like to see implemented. -- Ryan • (comments) • 17-Sep-2012 21:27 PDT