> I completely agree, but we also need a lower-level API that the higher- > level (JSP-170 level) API is a subset of, a simple API for file system > providers and for implementations that simply don't need the complexity > of JSR-170 (either from an installation, implementation or footprint > standpoint), a simple API that still has metadata support. Not sure how > to do that, but it IMO probably should be a requirement unless we're > going to let JSPWiki become a heavyweight-only application. I kinda like > the ability to just use a simple file system provider sometimes (and in > fact, ended up adding a file backend my XNodeStore a long time after > implementing a Xindice, Exist, and finally BerkeleyDB DB backends). Also, > for a lot of ISPs (mine, forinstance), it may be difficult to manage a > DB-based backend, even completely embedded. I like being able to simply > copy that 'pages' directory between version upgrades.
These are two different things. JSR-170 is the API that should be visible to the rest of JSPWiki. Of course, the API should be pluggable, that is, you can put in Jackrabbit or what-have-you as the JCR implementation. Jackrabbit will happily use also file storage, or you can even use something like HSQLDB, which stores all data as files, making managing them very easy. However, having said that, I do also see a need for something simple to ship with our product. Jackrabbit is a full-featured JSR-170 implementation with all the possible bells and whistles (of which we don't need most), and it's pretty big and needs external libraries as well. The file storage is also rather obscure, so direct file management the way that people are currently doing would be a bit complicated. Therefore, I started a small JSR-170 -implementation project called "Priha". It's not meant to be JSR-170 -compliant, but should fulfil all of our use cases, while retaining a very simple-to-use provider SPI, similar to the current JSPWiki PageProvider. It also needs few external libraries (it tries to use Java 5 built-in stuff as much as possible), and is pretty fast. I thought it would be cool to ship it as part of JSPWiki 3, and provide some nice migration path. Then the people who need serious enterprise grade performance can use something else, and people who are happy with just a simple implementation can use whatever is built-in. It already works to quite a large degree. If you want to start hacking away at it, you can check it out from cvs.jspwiki.org under the module name "Priha". At this stage I'd be happy to get some co-contributors on it :-) (By the way, in a completely unrelated matter, Java 5 + Hibernate + Stripes is a very cool combo. Using Stripes would make JSPWiki a *lot* simpler in the future.) /Janne
