Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-Id: <9E3C770C-90B6-4F18-9B24-E7C8670BC698@mac.com>
From: Andrew Jaquith <andrew.jaquith@mac.com>
To: "jspwiki-dev@incubator.apache.org" <jspwiki-dev@incubator.apache.org>
In-Reply-To: <20071023113913.GA18653@ecyrd.com>
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Mime-Version: 1.0 (iPhone Mail 3A109a)
Subject: Re: Issues register for JSPWiki metadata support?
Content-Transfer-Encoding: 7bit
Date: Tue, 23 Oct 2007 07:39:40 -0700
References: <471D6BE7.3020105@altheim.com>
 <53FB95CC-77B0-49DF-87BF-6926369541D8@ecyrd.com>
 <471DB872.3010800@altheim.com> <20071023113913.GA18653@ecyrd.com>

Janne - I haven't had as much time as I'd like to work ok JSPWiki  
lately, but when I am able to pop up for air, where should I commit my  
Stripes build? Pretty much all of the core class work is done,  
although the front-end classes (ActionBeans and JSPs) need work.

On Oct 23, 2007, at 4:39 AM, Janne Jalkanen <janne.jalkanen@iki.fi>  
wrote:

>> 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