Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Subject: Re: [New Repository] Major design issue concerning state
From: Rolf Kulemann <roku@apache.org>
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
In-Reply-To: <1081492487.2238.34.camel@gideon.rkunet.org>
References: <1081492487.2238.34.camel@gideon.rkunet.org>
Content-Type: text/plain
Message-Id: <1081495344.2238.41.camel@gideon.rkunet.org>
Mime-Version: 1.0
Date: Fri, 09 Apr 2004 09:22:25 +0200
Content-Transfer-Encoding: 7bit

On Fri, 2004-04-09 at 08:34, Rolf Kulemann wrote:
> Hello,
> 
> I see I'm lucky "moving that quick", because otherwise I never would
> have found out the following.
> 
> I did a small sample with the WebDAVRepository. I'm creating docs, read
> and write properties and version the docs via the WebDAV impl. of the
> "new repository". Lets have a look at the requirement to create a newly
> and LOCKED file in the repository. Using i.e. slides commandline client
> for WebDAV u simple execute a) "lock newfilename.xml" and b) "put
> src.xml newfilename.xml". BUT this only works within the same session.
> 
> That means if I lock into the webdav server a second time with the same
> user, b) is not possible, because the lock is not only associated with
> the user, but also bound to special session, here the first session.
> 
> To avoid this, the repsoitory impls. MUST act on the same WebdavResource
> during a user session, but this is not possible by design!
> 
> Why?: Normally the Sources i.e. c) WebDAVSource are wrapping a special
> d) WebdavResource. c) acts in all requests on the same d) which maintain
> the state.
> 
> I have thought about alternatives, but all lead to concept where we
> "need to pass around sth." reflecting the state. And that sth. is a
> Source imho.

Ok, I found maybe a solution for my special problem to create locked
resources in order to avoid races. I try to forget now, that there maybe
more state issues.

So it could be useful to add the following methods to the Repository
inteface or to the RepositoryVersioningHelper.

- createResource(String url, String content, boolean locked)

I think this would solve my major issue, because during the call, the
rep. impl can act for both operations (lock and put) on the same
WebdavResource. Of course this could be different implemented for other
repositories than WebDAV, but WebDAV behaves that way.

I will try to test such a method today.

Thoughts??

-- 
Regards,

    Rolf Kulemann