some comments on Priha (storage backend of JSPWiki 3)

[Florian Holeczek <fl...@holeczek.de>]

Hi developers,

I've just noticed that Priha has gone some steps forward the last
couple of days.

First of all, I'm happy to read that obviously the JSR-170 versioning
feature will be used. Besides scalability, I think a JSR-170 backend
has another advantage, when looking at JSPWiki from the users' point
of view: The wiki content will be accessible to other content
applications in a uniform way. Not using the built-in versioning
feature, but creating a proprietary one, would mean delimiting the
uniform access possibility JSR-170 provides. An application which
wants to retrieve specific versions would then have to know some
implementation details about the proprietary way of versioning.

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...
Getting a Repository object via JNDI is the only way which is
specified in JSR-170. When it comes to switching to another JSR-170
implementation, e.g. Jackrabbit, or connecting to a remote repository,
how do you want to request a Repository object without JNDI?

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.

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!

Best Regards,
 Florian

Re: some comments on Priha (storage backend of JSPWiki 3)

[Janne Jalkanen <Ja...@ecyrd.com>]

> 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