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.

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.

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.

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 ;-)