jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Jackrabbit physical folder
Date Wed, 21 Jun 2006 06:49:57 GMT
Hi,

On 6/21/06, Ramachandra Sankuratri <ramachandra.sankuratri@plateau.com> wrote:
> Please refer to JSR170-1.0.pdf(spec) - "5.1 A File System-backed Content
> Repository"(page41).
>
> Does it mean that the layout specified in this example cannot be
> retained in the file system-backed content repository?

The examples in the specification illustrate potential ways of
implementing the standard. Jackrabbit chooses a different approach of
using "item states" instead of files and folders as the principal
storage mechanism.

The item states are persisted through a persistence manager component
(of which we have a few) that decides the physical layout of the data.
However, the item state design doesn't really map well to a
traditional file system structure, it uses an id-to-content mapping
instead of path-to-content, so it would be quite difficult to achieve
the proposed storage layout.

Even more, Jackrabbit is designed to be completely in control of any
changes to the underlying storage, so even if we supported a
"traditional" file system storage, you wouldn't be able to modify the
contents of the files directly without major customization of
Jackrabbit.

What is your use case for wanting that kind of a storage model?

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message