Hi Andrey! This sounds very interesting as I have planned to consolidate the client and server api on basis of a new Slide API for Slide 2.2 or 3.0. Have a look at the Slide 3.0 design approach in the Wiki. If you are already working on separating the webdav logic from the web context this would be a big step in that direction! Please let me know more details about your ongoing work as I will start working on the new API soon. It will be more or less a simple mapping of WebDAV methods to Java methods. Thanks for your work so far! Cheers, Daniel
________________________________ Von: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Gesendet: Sa 28.08.2004 03:34 An: 'Slide Users Mailing List' Betreff: RE: Copy Macro Issue Hi, Kiran! I suspect that the incorrect behavior of the copy method might be just one more consequence of the big flaw in Slide's architecture - some important parts of WebDAV's logic (including versioning) are implemented in the "wedav" layer only - see the org.apache.slide.webdav package and its sub packages. That's why the majority of Slide users are working with the webdav client and don't use the "core" API directly. However, we've chosen a different approach and had to rewrite all required methods from the org.apache.slide.webdav.method package so they can be used in isolation from the web context. It's not an easy task (and I'm still not sure if we did everything correctly! :) ) so you probably should go with the client and ignore the core until it is rearchitected (in the 3d version, probably). Indeed, if you use the COPY method to copy a resource, a non-versioned copy of the resource is created if auto versioning is off and creates a versioned copy if auto versioning is on - but it's VHR is not the same as that of the original. This behavior is WebDAV-compliant, afaik. Yours sincerely, Andrey. > -----Original Message----- > From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] > Sent: Friday, August 27, 2004 8:20 PM > To: [EMAIL PROTECTED] > Subject: Copy Macro Issue > Importance: Low > > I am facing issues with using copy macro for copying > versioned objects. > Here > is a sample scenario: > > > > Original object: > > Name: XYZ.doc > > Number of Versions: 3 v1, v2 and v3 > > Checked-in property value: v3 > > > > 1. Copy the object using the copy macro. The Destination > copied object has the following properties: > > Name: CopiedXYZ.doc > > Checked-in property value: v3 > > > > The problem is both the original and the copied object are > referring to the same history node v3. > > > > 2. Add a new version v4 to the original object: > > Name: XYZ.doc > > Number of Versions: 4 v1, v2, v3 and v4 > > Checked-in property value: v4 > > > > 3. At this point the new (copied) object still has the > checked-in property as v3. > > Name: CopiedXYZ.doc > > Checked-in property value: v3 > > 4. Now try adding a new version to the new (copied) object. > This will throw a precondition violation say that checkouts > with descendants is not allowed. > Since I am trying to check out v3, when there is already a > successor for v3, which is v4 created by the original object. > > > > This seems a pretty basic flaw in the copy macro. Ideally it > should be creating new history nodes for the new (copied) > object. Is this a known issue? Does the copy macro does > support copying versioned objects? If it does, this problem > should be fixed. If it does not, it should not be copying > version related properties. > > > > Thanks > > Kiran --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
