I've just noticed that Priha has gone some steps forward the last couple of days.
Dang, I'm busted. Yes, I'm concentrating on that for now. It's very liberating to work on something completely new, you know - sometimes JSPWiki feels too much like work :-)
First of all, I'm happy to read that obviously the JSR-170 versioning feature will be used.
Would like to use the simple versioning, but I'm not sure whether that is an option - the JSR-283 license expressly forbids from making any real implementations based on it, until it's stable.
Besides scalability,
My tests suggest that Priha is currently (with ehcache and hsqldb) not significantly losing to Jackrabbit 1.4 performance-wise, even without major optimizations. I was also planning to write a JspWikiVersioningFileProvider soon to test the theory that you should be able to use your existing repository without any major changes (you will probably need to rename the directory where you keep the files or something).
Another point I've been reading in the README file is that JNDI support is an anti-goal. I'm not sure what is meant with this...
Read: Janne does not understand JNDI, and JNDI access to JCR is not standardized. Noticed yesterday that JSR-283 does have a standardized method for doing it (with sample code), so if I manage to wrap my brain around JNDI...
In the mean time, adapter classes are probably the jspwiki way forward. I would hate to split some of our configs to a property file, some config to JNDI, some config to random XML files, etc. Something like
"jspwiki.repository = [adapterclass | jndi], where the value "jndi" means "look in JNDI".
The whole configuration business in jspwiki 3 needs some thinking. I would like to move to a web-based config interface...
Third, the current package names are org.jspwiki.*. Since it will be an Apache release, it would be good to already switch to the correct package names now, I guess.
Priha is not an ASF-endorsed project. It's a separate thing, and will probably stay as one. I was planning to switch it to "com.ecyrd.priha" though, because in the long term, jspwiki.org should probably move to ASF.
Overall, I think Janne's approach is really making large installations possible without giving up JSPWiki's principles of being small and simple. Very nice!
Thanks :-). At the moment, Priha requires *no* external libraries aside from jcr-api.jar (and I intend to keep it that way, even though I'm feeling the pain of using Java5 logging libraries). It will take advantage of ehcache if it's found in the classpath, but with local DB storage, the performance gain of caching is rather small. So it should be a nice, embedded library that's easy to configure and integrate seamlessly into JSPWiki.
BTW, priha is currently fully functional (and passes most of the TCK tests). I'm now concentrating on working on optional features, such as locking and versioning.
/Janne
