Yes, I understand that this is a decision for 3.0. I think in some
ways
it's obviously a good one, and in others a truly terrible one. If
there
is no way to use a non-JCR provider with 3.0, JSPWiki will cease being
a simple wiki -- we've then moved firmly into the CMS range of
applications.
We gain a lot of benefits, but if say, there's no file-based
provider, no
way of having a simple wiki, then we've also *lost* something
rather vital.
There will be a simple file-based provider as well. Hopefully ~90%
compatible with the current VersioningFileProvider (you might need to
create an extra directory and move all your stuff in there).
JCR is a relatively sane provider API, and it's far better to use
something standardized than our own half-cooked one. One of the
*big* problems we're currently facing are simple scaling issues, and
a lot of it comes from the fact that our backend is braindead and
cannot really be optimized properly.
As far as I can see, we can either try to replicate the work done by
way smarter people than us to figure out what the repository API
should be, switch completely and *only* to SQL (e.g Hibernate), or
adopt JCR.
I'm currently writing a very light-weight JCR implementation, which
requires little or no external library dependencies, and can be
adapted to support current JSPWiki FileProviders with little pain.
/Janne
