Thinking about wiki backends
Published July 28th, 2006 in GeneralLately I’ve been thinking a lot about wiki backends. Others have thought about new weblog backends. From my point of view, most wikis in the Java world use ORM oder mostly JDBC backends. Currently there is a lot of buzz about JPA. JPA is a great standard to unify ORM apis and would enable users change the ORM solution in their wiki with a drop in replacement. Others do this with their app server successfully.
But for wikis the JPA abstraction level is still to low level. Much better suited is JSR 170 aka Content Repository for Java (JCR) 1.0 and the upcoming next version. Applications can specify their needs for content storage on a high abstraction level with metadataed (= property) chunks of content. There can be title, content, attachments and author properties (JCR tutorial). If all wikis share the same property namespace and the same standard markup, users could change their wiki implementations without the need to migrate data. Just start the new engine. Users could even run two wiki engines for different needs on the same content backend.
Imagine a JCR implementation (Jackrabbit please!) which uses JPA. Best of two worlds: High abstraction and content portability and plugable ORM and JCR implementations.
That were just some of my thoughts on wiki backends 2006 style.
I personally think that JCR is too complicated. I don’t mind the arbitrary metadata and versioning and stuff. That’s great. I would just rather have a simpler core. Stated otherwise, the spec seems way too large to be the core that I want. And I’m also usually fonder Subversion-style versioning and atomic changesets and so on.
I’ve hypothesized how I might like to see it, but I haven’t dedicated any time to it. Maybe someday. I do like the idea of a combined wiki/blog like SnipSnap. I just don’t like SnipSnap itself. I also wonder at JIRA and Confluence. Seems to me like a bug tracking system could almost just be a very simple module on top of a wiki. But I haven’t much used JIRA or Confluence, so I can’t speak much to them.
And I’ve also gotten sidetracked from your original subject, but maybe not too far. Use cases are helpful in thinking about implementation.
I think JCR is quite simple, and has a simple and clean concept. For my feeling though, Jackrabbit is a bit of a gorilla and could be thinner. A small JCR-driver over JPA would be nice.
With JCR and Radeox it’s very simple to start your own wiki.
Yes, trac tries to be a wiki bugtracker, though the concept doesn’t work with me. But a bug tracker on top of a meta data wiki might be easy to write. Something along
#bug{ Posting does not work with Tomcat } somewhere in the page.
Not too far.
JCR is nice, the spec covers lot’s of stuff and with 2-3 days work I was able to use versioning and metadata (with jackrabbit) and had my wiki prototype using radeox up and running. I need to check back again for the xpath queries in jackrabbit it had some problems as I tried it otherwise I will use JCR for everything wiki/blog/cms related I might do. I just don’t want to deal with databases, object mappings or something like that anymore.
@Olli: 100% ack.