Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <433D0883.4010203@gmx.net>
Date: Fri, 30 Sep 2005 11:42:27 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Model 3 deployment status
References: 
 <097BBD8F4914294699F8CE37FAF6C9A23839DA@AK1VXCH01.tvnzad.tvnz.co.nz>
In-Reply-To: 
 <097BBD8F4914294699F8CE37FAF6C9A23839DA@AK1VXCH01.tvnzad.tvnz.co.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Phil Bingley wrote:
> While I am new to Jackrabbit, I for one would love to see an
> implementation like that. I have been looking at my options for an
> implementation of jackrabbit and felt that I couldn't achieve exactly
> what I needed with jcr-rmi because of the performance issues.
> 
> In this case, doesn't it amount to creating remotable versions of things
> like the PersistenceManager and FileSystem - at least things at a layer
> similar to them. It feels to me like having JCR able to sit on top of
> the network layer might make the clustering issue easier to overcome also.

creating a 'fat' remote client for jackrabbit and using jackrabbit in a 
cluster is basically the same problem. both try to do as much work as 
possible in isolation from other clients / cluster-nodes while care has 
to be taken to ensure consistency when changes are actually committed.
The second requirement inevitably results in the question how changes in 
the central storage are propagated to connected clients / cluster-nodes. 
  Which can be quite tricky when one tries to use a connection less 
protocol ;)

> Ideally I'd like to be able to have a rich client use the JCR API
> remotely against the same data as a webapp using the JCR API with local
> calls to the underlying data. I was thinking that I'd be able to
> implement a PersistenceManager etc to enable this but after doing a lot
> of reading there would be caching etc internal to JackRabbit that would
> stop this from working. This is basically what gets in the way of
> clustering isn't it?.

There are numerous areas that need to be reworked. See jira issue JCR-169.

> Am I heading in a bad direction with my ideas or would this be a
> workable solution?

I think you are heading in the right direction. Feel free to dump your 
thoughts to the mentioned jira issue.

regards
  marcel