You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-user@jakarta.apache.org by jo...@cexp.com on 2003/01/28 16:18:57 UTC

webDAV servlet and PUT/MOVE concurrency

Greetings,
	I know that webDAV specifies that a MOVE command will do a copy and
delete, but that takes too long on our target box.  What is the best way to
change the behavior of the servlet so a MOVE does a move?
	Since my remote files are picked up by a scheduled job (runs every
few seconds), it must land completely in the directory all at once.  Up
until now we've been using a custom servlet that writes the file to a temp
directory and the moves it to the final directory.  Now we're looking to use
webDAV to make our software more compatible, but it has to fit this
constraint.
	I was thinking of subclassing the servlet and just changing the MOVE
functionality.  Is there a better way?
Thanks,
Joe

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: webDAV servlet and PUT/MOVE concurrency

Posted by Michael Smith <ms...@speedlegal.com>.
joe.fair@cexp.com wrote:
> Greetings,
> 	I know that webDAV specifies that a MOVE command will do a copy and
> delete, but that takes too long on our target box.  What is the best way to
> change the behavior of the servlet so a MOVE does a move?
> 	Since my remote files are picked up by a scheduled job (runs every
> few seconds), it must land completely in the directory all at once.  Up
> until now we've been using a custom servlet that writes the file to a temp
> directory and the moves it to the final directory.  Now we're looking to use
> webDAV to make our software more compatible, but it has to fit this
> constraint.
> 	I was thinking of subclassing the servlet and just changing the MOVE
> functionality.  Is there a better way?
> Thanks,
> Joe

The WebDAV specification says that a MOVE must be equivalent to a COPY 
then a DELETE, not that it must be implemented as such. An 
implementation that actually moves the files directly would be perfectly 
valid. However, slide does not have any way to so such a modification in 
its internal store interfaces - adding it would be possible, but a 
non-trivial amount of work.

Mike



---------------------------------------------------------------------
To unsubscribe, e-mail: slide-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-user-help@jakarta.apache.org