On 2/2/06, Phillip Rhodes <[EMAIL PROTECTED]> wrote: > > I have been going over the docs and hoping to have some confirmation > before I commit further. > > I am looking to implement a library (in tapestry) that would allow users > to upload and display content within a webapp (images, html, etc). I > would like to abstract the content storage so that it can be stored in > webdav, dbms, file system, etc... > > By writing my library with jackrabbit, would I be giving the users of my > library the capability of using these other repo's, while still working > "out of the box" with a filesystem?
Depends what you mean. Obviously Jackrabbit is not a magic integration device that somehow automatically provides a single API for accessing existing legacy content stored in repositories, databases and filesystems that you already have lying around. But Jackrabbit can be configured to store (new) content using a variety of different underlying storage mechanisms (databases, file systems etc.). The real point of Jackrabbit is that it is an implementation of JCR. If you wrote your library using JCR (not 'Jackrabbit' per se) the advantange would be that you could then also use the same library with other JCR implementations. That's the actual *point* of Jackrabbit. The fact that a number of persistence managers are available is not really the core issue. Cheers, Peeter
