Hi,
On 6/21/06, Ramachandra Sankuratri <[EMAIL PROTECTED]> 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/ - [EMAIL PROTECTED]
Software craftsmanship, JCR consulting, and Java development
