jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Considering Jackrabbit
Date Mon, 18 Jul 2005 11:04:55 GMT
hi andy,

thanks for comments, i think you are touching on a couple of issues.

> 1. Using a relational database for storage, which would allow us to leverage
> all the work we have already put into making sure our relational database is
> scalable, fault tolerant, etc...
hmm... first: keeping your relational database fault tolerant and 
consistent and keeping your repository fault tolerant and consistent
are unfortunately two separate issues even if you persist you items
in an rdbms.

to me it seems like we have a number of people on this list 
asking for a jdbc persistence manager, but the one that we 
have (the "orm pm") does not receive enough development 
support by all those people that are interested in it?

if that really is the case then i would suggest that some
of the people that are using the orm pm are pitching in to 
catch up with the rest of jackrabbit and make it 
"production ready" ( whatever that means for an 
unreleased project ;) )

i think that having another jdbc approach without scraping 
the orm pm will only spread the seemingly small *developer*
base interested in supporting rdbms backed repositories even 

does anybody have an idea or a comment? is there a problem with
the orm implementation? why are there not enough efforts put
into it by the parties interested in it? would people favour a more
direct jdbc implementation?

> 2. Client/server.  We will need "model 3":
> http://incubator.apache.org/jackrabbit/arch/deploy/howto-model3.html - our
> document repository will be an integral part of our application, which will
> be running in a cluster.
> For model 3, the RMI implementation looks too
> weak (not optimized - slow over WAN), and it's hard to tell how mature the
> WebDAV implementation is at a glance.
jackrabbit features two flavours of webdav:

(a) complete remoting server for all the jsr-170 calls using 
delta-v, dasl, order, subscribe, ...

(b) a server that exposes the repository as a filesystem to
work easily with dav_mount, windows webfolders and the

in my experience (b) works quite nicely for "document 
repositories" since those are operating most of the time on 
a "blob+'meta'-properties" basis, and people frequently are very 
happy with the fact that they can just use the "content repository" 
as a fileserver and tie some magic to the "put" on the repository


View raw message