http://marc.theaimsgroup.com/?l=slide-dev&m=108057214410350&w=2
Right now the only method of WebdavResource being "user-aware" is unlock() which seems a little inconsistent IMO. The required changes to the WebDAV repo impl can only be made after upgrading to RC1.
Yes, I thought about "how much state" the Repository should manage, and still opt for a stateless approach. I really can't see how this conflicts with SourceRepository since it rather expands on it.
Guido
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.
That is why I think the old SourceRepository concept is better, because it is state aware since it acts on if wanted "stateful sources".
What is the disadvantage not being able to lock a non existent file in order to create it?
Answer: Race issues. Lets create a new resource with put in order to lock it afterwards. There is potential room for race conditions!
I really wonder, how this should be solved with the "new approach". Even
having ONE RepositorySource (to rule them all) would not solve it,
because it needs to wrap backend specific state which is in case of
WebDAV the WebdavResource. Thus we need single Source impls. for each
backend taking care of state.
At the mom I recommend to extend the "old repository concept" with versioning i.e. add methods - checkout() - checkin() - uncheckout() - setVersioned()
to the VersionalbeSourceInterface.
WDYT???
