incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terry Steichen <>
Subject Re: JSPWiki 3 design notes
Date Tue, 05 Feb 2008 16:49:58 GMT

What would that do to those of us using the JDBCPageProvider (and the
thousands of pages implemented via that WikiPageProvider)?


PS: Sorry, but I'm also beginning to wonder if these grand and glorious
plans aren't taking JSPWiki in a direction that will drastically alter
the characteristics that attracted me to it from the outset.

On Tue, 2008-02-05 at 18:12 +0200, Janne Jalkanen wrote:

> > So you don't see any way of using a JSPWiki 3.0 implementation
> > *without* JSR-170?
> Exactly.  It would be duplication of work.  And mostly really stupid  
> work, too, since it would mean reinventing the JSR-170 concepts.
> > I'm rather surprised, really. One of the real
> > strengths of JSPWiki is that there's a nice, lightweight file
> > system implementation too.
> The job of the lightweight file system implementation is the job of  
> the backend, in this case, JSR-170.  It makes a lot of sense to  
> separate backend (i.e. storage) under a separate API, and where we  
> now use the WikiPageProvider, we can get far better support by using  
> JCR.
> > If the entry ramp is a complex database
> Nobody said anything about complex databases.
> I have, over the past year, been writing a lightweight implementation  
> of JSR-170, which uses a very similar pluggable provider system like  
> the current WikiPageProvider.  And yes, it ships with a lightweight  
> file system provider as well.  And no, it does not pass the TCK yet.   
> And yes, I was planning to offer it as the default JCR Repository for  
> JSPWiki 3, and yes, users who need HA or scalability can then switch  
> to Jackrabbit at the flick of a switch.
> Murray, calm down.  I wouldn't want to throw away the advantages of  
> JSPWiki, and I also still do not particularly like databases.
> /Janne

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message