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 thinner. 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 likes. 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 backend. regards, david
