Hi,
A MOVE request is handled by Macro.move which performs a copy followed
by a delete.
This has the following drawbacks:
- The underlying store might provide an API for moving that is much
faster. In unix terms:
moving an INODE is much faster than copying a complete sub-tree and
deleting the source
afterwards. I would suggest adding 'moveXxx' methods to the various
store interfaces just like
'createXxx', 'retrieveXxx', 'storeXxx', etc. (the default
implementation could still be copy followed by
delete).
- The permissions for deletion are checked after the copy operation.
This means that you need to
wait for the full copy operation (and it's rollback) before an error
response is sent.
A DELETE request is handled by Macro.deleteObject which performs a
recursive delete of the complete sub-tree.
Just like with MOVE the underlying store might have a direct API that
performs a recursive delete.
Previously Krister Saleck has asked for something like this (subject:
Server-side WebDAV API)
Remy suggested him two options. One of them was:
- If you only want legacy WebDAV level 2 support, without anything
fancy, you can use Tomcat 4 and write a JNDI directory context which
would access your repository
Does this mean that you only need to write the JNDI directory context
and that Tomcat 4 provides the WebDAV stuff?
(I am still using Tomcat 3.2.2)
Regards, Nelis
