COPY and Methods

In this paper I am going to talk about COPY's definition as it relates to
the behavior of the copied resource at the destination. I will leave the
issue of COPY and properties to another paper.

When the COPY and MOVE debate began it was almost instantly agreed that MOVE
somehow inherited COPY's functionality. The exact nature of the inheritance
was left open but it was felt that we first had to get our definition of
COPY right before we could deal with MOVE. Thus the WG worked first on COPY.

In order to understand what it means to copy a resource one must first
understand the nature of an HTTP resource. HTTP defines a resource in terms
of how it responds to methods. The actual implementation of the resource is
left as an open question. This flexibility allows HTTP resources to be
files, CGIs, databases, extensions, etc.

Thus the most obvious definition of the COPY method was something along the
lines of "The result of a COPY method is to create a new destination
resource, whose state is independent of the source resource, which responds
to the same methods in the same way as the source resource."

This definition lasted about the length of time it took to utter it. For
example, imagine one has a resource that maps to a file in a directory. The
directory is CGI enabled. A user then tries to copy the resource to another
directory that doesn't have CGI support. The previous definition would
require the attempt to fail because clearly the destination resource would
not "respond... to the same methods in the same way as the source resource."
Everyone instinctively understood that failing the previous scenario made
COPY less than useful.

There was some thought of defining a switch which would determine if a COPY
should be strict or not. A strict copy would work as the previous definition
and a loose copy would just do whatever it wanted. But nobody felt the
definition of "strict" could be satisfactorily nailed down. Phrases like
"respond... to the same methods in the same way" were too murky. The only
way to come up with a completely reliable definition was to re-invent
COM/CORBA so we could exactly define what a resource was. Then we would
either have to put in negotiation based on environment, processor, etc. or
try to adopt some universal portable environment like JAVA. Most folks in
the WG could actually feel themselves sliding down the slope heading for the
bottomless pit.

The consensus was that COPY was going to be a "magic" method. Its behavior
would be a function of who controlled the source and destination. So you
better know what you are doing before you execute the COPY. If you were
copying around files, everything would pretty much work the way you
expected. If you tried to copy anything more complicated, your mileage would
vary.

I realize that this definition would seem to be counter to the goal of
interoperability but it accurately reflects how systems work today. If you
want your CGI file to be properly executed you better know where the CGI
enabled directory is. If you want your ISAPI filter to run, you better know
how to register it (way out of scope for WebDAV). Even things as simple as
wanting to copy a file to a disk require that you know the name of the disk
drive. In general copy gets leveraged to implicitly provide many services
because copy is the programmatic equivalent of drag and drop. What happens
when you drag object A over object B completely depends on the nature of A
and B.

Killing the magic would just break ranks with current implementations
without providing any real user benefit. We would have the best-defined COPY
method that no one ever used. 

In the end the WG agreed and defined copy as the creation of a new resource
at the destination whose initial state was related, in an unspecified
manner, to the state of source resource at the time of the COPY. Certainly
not perfect but in practice it has proven to be good enough.

Received on Monday, 8 February 1999 18:11:42 UTC