Forking Radeox: A new wiki render engine
Published August 20th, 2007 in Java, WikiAfter some debate of getting the rights to Radeox and a some negotiations I decided to fork Radeox. Radeox is an open source wiki render engine for Java which turns wiki markup into HTML and which is successfully used in several wikis. For years I was the lead developer for Radeox but that changed when I got a new job.
The past
- Radeox was used in SnipSnap and refactored to it’s own project
- The license was changed to Apache, the API license was changed to BSD
- Work on Radeox was done during my employment at Fraunhofer FIRST, who own the rights to some of the code
- The ideas, the API and some implementation predate SnipSnap and Fraunhofer
- At Fraunhofer Radeox was cleaned up, refactored and extended with features
The name is owned by me so although I fork Radeox I still keep the name. Radeox is available on the Reposita SVN server.
The future
The development of wikis is not over. From my point of view what we see is just the beginning of wikis. We have only seen the tip of the iceberg. Wikis are still growing steadily, just take a look at google trends (not scientific blah blah blah):
I’ve been developing, consulting and thinking about wikis for 8 years, my first self-developed wiki is dated 1999. SnipSnap as a wiki was very successfull for some time. I talked to lots of people about the future of wikis and what they think in which direction wikis will move. I attended several WikiSym events and was helping to organize one. At the last WikiSym I gave a workshop and co-wrote a paper (PDF) about wiki render engines: “The Radeox Wiki Render Engine”. The discussion around the paper sparked several revolutionary ideas and I will implement some of them in the next Radeox version. Wiki engines didn’t innovate in the last years, so it’s time for change and a speedup in innovation. Innovation in rendering engines will spark innovation in wiki implemtations. May we live in interesting times.
Thanks for listening.
7 Responses to “Forking Radeox: A new wiki render engine”
- 1 Pingback on Oct 3rd, 2007 at 2:04 pm
This is great news! I’m starting a new app that will be a great fit for Wiki editing, but I was really worried about what was happening with Radeox, especially when the web page went down. I’m glad to see you’re getting it moving again. Any hints on what the innovations will be?
Glad to see Radeox going further!
Regarding your comment on lack of innovation in the wiki engine area, I have to disagree as I’ve seen great progress lately on advanced second-generation engines like XWiki (http://www.xwiki.org) which lets you build full-blown applications on top of its platform. Awesome stuff in perspective… you should have a look at it ;-)
First of all, thanks for using Radeox and being interested for a long time.
I know XWiki and talked to the people at WikiSyms. Nice and clever. I also talked to the JotSpot guys. Yes there is innovation regarding wikis as a plattform (I wrote wiki plattform stuff in 2001, there should be an excel like table in Radeox ;-) The SnipSnap predecessor was a social network / knowledge management / tagging plattform which integrated a wiki.
But there is no wiki business integration, workflow, domain specific language and adaption innovation (some small projects try this and I think TWiki does consulting on parts of that). There is no backend innovation (Wiki on top of Alfresco CIFS anyone?). Wiki specific JSR? Exchangable wiki backends? Parallel access to a wiki backends by JSPWiki and XWiki? And I can think of much more :-) And last not least I wrote “wiki engine” innovation, not wiki innovation. There is still - as far as I know - no working refactoring tool for wiki content. There is no Wiki/Source-Code integration.
This is great news. I am using radeox in my toy blog project and it’s great to see it revived. Thanks Stephan
Hi Stephan,
There is backend innovation. We have an experimental JCR storage (on top of JackRabbit and eXo JCR) in XWiki.
We are also working on Wiki replication (P2P and Offline).
Concerning syntax there is WikiCreole for standardization.
I agree also about Excel. We have an experimental integration with Google Spreadsheet
http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Google Docs Integration
As far as Radeox is concerned, did you have a look at WikiModel (http://wikimodel.sourceforge.net/). We are looking at this for XWiki.
Hi Ludovic,
excellent to hear! “Wiki specific JSR.” I think an JCR backend is the right direction but not enough. For JCR there should be a wiki standard for nodes like title, content etc. to allow several wiki engines to sit on top of one JCR storage. Then they should use the same content model or Creole.
I’ll take a look at wikimodel, I hope to integrate an AST into Radeox as a next step. Does wiki model support Creole? I also think that a buttom up parser like Tatoo would be a much better idea than a top down parser like JavaCC.
P2P! I discussed a server-less P2P wiki for more than 5 years with leo, we think this would allow for revolutionary wiki usage. We never had the manpower to implement those ideas though. I’m curious about the XWiki P2P results. Great work.