RE: Jackrabbit physical folder

[Ramachandra Sankuratri <ra...@plateau.com>]

My UseCase is as follows.

Say a HTML file is stored in the Jack Rabbit Repository. It has to refer
to a .jpg file that is also stored in the Repository. How is this
reference done so that it is valid both at the time of design (content
editing) and after publishing.

Thanks
Chandu

 
-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
Sent: Wednesday, June 21, 2006 2:50 AM
To: users@jackrabbit.apache.org
Subject: Re: Jackrabbit physical folder

Hi,

On 6/21/06, Ramachandra Sankuratri <ra...@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
The information contained in this e-mail message is intended only for the personal 
and confidential use of the recipient(s) named above. This message is privileged 
and confidential. If the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you are hereby notified 
that you have received this document in error and that any review, dissemination, 
distribution, or copying of this message is strictly prohibited.

Re: Jackrabbit physical folder

[Chris Miner <ch...@luxoom.com>]

Perhaps I don't understand your question, but isn't this how it already
works out of the box?  For example fire up the downloadable demo,
and edit the main page.  Add a "Samples: Text and image paragraph".
Choose an image off the file system.  It is uploaded and resides in the 
repository.  Preview the page, and the image is delivered.  The  publish the 
page and again everything is there.  Is this not what you are wanting?

On Monday, 10. July 2006 15:33, Ramachandra Sankuratri wrote:
> My UseCase is as follows.
>
> Say a HTML file is stored in the Jack Rabbit Repository. It has to refer
> to a .jpg file that is also stored in the Repository. How is this
> reference done so that it is valid both at the time of design (content
> editing) and after publishing.
>
> Thanks
> Chandu
>
>
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Wednesday, June 21, 2006 2:50 AM
> To: users@jackrabbit.apache.org
> Subject: Re: Jackrabbit physical folder
>
> Hi,
>
> On 6/21/06, Ramachandra Sankuratri <ra...@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